KDU internally throws kdu_exception, which is a typedef for int. It's possible
that such an exception might leak out.
Our usual strategy for unknown exceptions is to catch (...) and let
boost::current_exception_diagnostic_information() handle them. However, for
int (or a class not derived from std::exception), that function will only
shrug and report no information available.
Besides, we want to format kdu_exception specially anyway. First, the KDU
#defines are in hex, so we should report the value in hex. But on inspection,
certain of those hex values are actually multibyte ASCII literals in disguise
-- so also report the byte string value.
Turns out we have a surprising number of catch (...) clauses in the viewer
code base. If all we currently do is
LL_ERRS() << "unknown exception" << LL_ENDL;
then call CRASH_ON_UNHANDLED_EXCEPTION() instead. If what we do is
LL_WARNS() << "unknown exception" << LL_ENDL;
then call LOG_UNHANDLED_EXCEPTION() instead.
Since many places need LOG_UNHANDLED_EXCEPTION() and nobody catches
LLContinueError yet, eliminate LLContinueError& parameter from
LOG_UNHANDLED_EXCEPTION(). This permits us to use the same log message as
CRASH_ON_UNHANDLED_EXCEPTION(), just with a different severity level.
Where a catch (...) clause actually provides contextual information, or makes
an error string, add boost::current_exception_diagnostic_information() to try
to figure out actual exception class and message.
Previous code would crump with LL_ERRS. But a bad image file should fail only
the image load -- not crash the viewer.
While at it, validate all components present, not just 0, 1, 2.
While at it, make the failure message report which component and what the
mismatched dimensions are, not just "Components don't have matching
dimensions!"
Specifically, manually apply changesets b4db8a8 and b98371d from
nat_linden/viewer-mac-mainloop. We need to throw from a new place, but if we
threw const char* (current convention), the new throw wouldn't be patched when
we merge to new exception convention.
These comments are inherently fragile, in that they enumerate all present
callers of certain methods. Adding, removing or relocating calls would
invalidate these comments. However, the LLImageJ2CKDU implementation is
probably pretty stable by now.
The only call to the findDiscardLevelsBoundaries() method was commented out
inside initDecode(), with a comment:
// Merov : Test!! DO NOT COMMIT!!
This was the only caller of copy_tile(), which was the only caller of
copy_block(). Commented out all three of these (biggish!) functions, since I
have no idea what any of them were supposed to do or when it might be useful
to call them. In other words, I can't yet rule out the possibility that I
might have to uncomment them.
Use boost::scoped_ptr instead of raw pointers to LLKDUMemSource,
LLKDUDecodeState, kdu_coords and kdu_dims so cleanup is simpler, and automated
on destruction of LLImageJ2CKDU.
Replace pointer to kdu_codestream with a custom RAII class. kdu_codestream is
itself an opaque handle, so we don't need to add another layer of indirection.
Just wrap it to ensure its destroy() method is reliably called when needed.
Make static instances of LLKDUMessageWarning and LLKDUMessageError
self-register, eliminating the companion static bool and explicit checks in
code.
Derive them both from a common base class that does the message logging,
instead of having each handler class log redundantly -- especially since the
put_text() override accepting const kdu_uint16* was simply streaming the
kdu_uint16 pointer to the log file, which would log the hex value of the
pointer.
Although we want a static instance of each of these handler classes, pull it
out rather than nesting the instance within the class itself.
Specifically, remove unused function pointer types CreateLLImageJ2CFunction,
DestroyLLImageJ2CFunction and EngineInfoLLImageJ2CFunction.
Also eliminate static fallbackDestroyLLImageJ2CImpl() and
fallbackEngineInfoLLImageJ2CImpl(), leaving only static
fallbackCreateLLImageJ2CImpl().
We do need a factory function to instantiate the appropriate LLImageJ2CImpl
subclass, so leave the fallbackCreateLLImageJ2CImpl() link seam in place.
However, given that every known LLImageJ2CImpl subclass is cheap to
instantiate, make getEngineInfo() a pure virtual method on that subclass: the
static LLImageJ2C::getEngineInfo() method can temporarily construct an
instance to query. While we're at it, make getEngineInfo() return std::string
like LLImageJ2C::getEngineInfo(). It's ridiculous that
fallbackEngineInfoLLImageJ2CImpl() implementations constructed a static
std::string and returned its c_str(), only to have LLImageJ2C::getEngineInfo()
construct ANOTHER std::string from the returned const char*.
fallbackDestroyLLImageJ2CImpl() never did anything useful: it merely deleted
the passed LLImageJ2CImpl subclass pointer as the specific subclass type. But
since LLImageJ2CImpl's destructor is virtual, LLImageJ2C's destructor could
simply delete the stored LLImageJ2CImpl*. In fact, make mImpl a
boost::scoped_ptr<LLImageJ2CImpl> so we don't even have to delete it manually.
destroyLLImageJ2CKDU().
These were apparently intended as simple C-style DLL entry points. But as
nobody calls them, and as we decided against building the viewer from DLLs,
they only clutter the code.
This also introduces LLContinueError for exceptions which should interrupt
some part of viewer processing (e.g. the current coroutine) but should attempt
to let the viewer session proceed.
Derive all existing viewer exception classes from LLException rather than from
std::runtime_error or std::logic_error.
Use BOOST_THROW_EXCEPTION() rather than plain 'throw' to enrich the thrown
exception with source file, line number and containing function.
whose body reads:
// *FIX: This exception is bad, bad, bad. It gets thrown from a
// destructor which can lead to immediate program termination!
throw "ll_kdu_error() throwing an exception";
which would be bad indeed... if ll_kdu_error() were ever actually referenced
by anything!
KDU 7.8 introduces a number of changes to its API, most notably by moving
public symbols into a variety of kdu_something namespaces. While this is
laudable in a general sense, it does require quite a bit of diagnostic
building and patching to update legacy code.
Since llimagej2ckdu_test.cpp lamentably stubs out pretty much the entire KDU
API, we must also fix those stubs for signature changes even to functions we
don't otherwise reference.
NOTE: This commit still leaves four symbols undefined. Below I have taken the
liberty of juxtaposing the error line with the output from dumpbin /exports
build-vc120/packages/lib/release/kdu.lib. I see no differences.
unresolved symbol (?kdu_convert_ycc_to_rgb_rev16@kdu_core@@3P6AXPAF00H@ZA) "void (__cdecl* kdu_core::kdu_convert_ycc_to_rgb_rev16)(short *,short *,short *,int)"
?kdu_convert_ycc_to_rgb_rev16@kdu_core@@3P6AXPAF00H@ZA (void (__cdecl* kdu_core::kdu_convert_ycc_to_rgb_rev16)(short *,short *,short *,int))
unresolved symbol (?kdu_convert_ycc_to_rgb_irrev16@kdu_core@@3P6AXPAF00H@ZA) "void (__cdecl* kdu_core::kdu_convert_ycc_to_rgb_irrev16)(short *,short *,short *,int)"
?kdu_convert_ycc_to_rgb_irrev16@kdu_core@@3P6AXPAF00H@ZA (void (__cdecl* kdu_core::kdu_convert_ycc_to_rgb_irrev16)(short *,short *,short *,int))
unresolved symbol (?kdu_convert_ycc_to_rgb_rev32@kdu_core@@3P6AXPAH00H@ZA) "void (__cdecl* kdu_core::kdu_convert_ycc_to_rgb_rev32)(int *,int *,int *,int)"
?kdu_convert_ycc_to_rgb_rev32@kdu_core@@3P6AXPAH00H@ZA (void (__cdecl* kdu_core::kdu_convert_ycc_to_rgb_rev32)(int *,int *,int *,int))
unresolved symbol (?kdu_convert_ycc_to_rgb_irrev32@kdu_core@@3P6AXPAM00H@ZA) "void (__cdecl* kdu_core::kdu_convert_ycc_to_rgb_irrev32)(float *,float *,float *,int)"
?kdu_convert_ycc_to_rgb_irrev32@kdu_core@@3P6AXPAM00H@ZA (void (__cdecl* kdu_core::kdu_convert_ycc_to_rgb_irrev32)(float *,float *,float *,int))
24>C:\Users\Nat\linden\viewer64\build-vc120\newview\RelWithDebInfo\secondlife-bin.exe : fatal error LNK1120: 4 unresolved externals
Rye