| Age | Commit message (Collapse) | Author |
|---|
|
Specifically, log as LLSingleton captures inter-Singleton dependencies. Also
log cleanupAll() calls to cleanupSingleton() and deleteAll() calls to
deleteSingleton(), since they happen in an implicitly-determined order. But do
not log anything during the implicit LLSingletonBase::deleteAll() call
triggered by the runtime destroying the last LLSingleton's static data. That's
too late in the run; even std::cerr might already have been destroyed!
|
|
|
|
Introduce corresponding llcleanup.cpp, llinitdestroyclass.cpp modules to
contain code that performs logging calls.
Track class::method names for LLInitClass<T> and LLDestroyClass<T> subclasses,
and log them when called. The order in which these calls occur could be
relevant to bugs, and could surface the need to convert to LLSingleton
dependencies.
|
|
It used to contain an LLSingleton called Singleton, requiring
LLGlobalEconomy::Singleton::instance() to access it rather than the
conventional LLGlobalEconomy::instance(). This has been fixed, so normalize
references accordingly.
|
|
LLSingleton::getIfExists() has been eliminated. The only remaining way to
detect whether a given LLSingleton has been instantiated is to call
instanceExists(). But the relevant cleanup code should be refactored to
cleanupSingleton() anyway, which would make this specific call moot.
|
|
This fixes fatal warnings.
|
|
clang gets nervous about expressions that call functions inside typeid(), even
though these particular typeid() calls are runtime expressions on runtime
values. Extract the offending calls to a previous statement.
|
|
|
|
|
|
|
|
|
|
|
|
This particular test relied on there being exactly one instance of the string
"indra" in the source file's __FILE__ path -- which is usually true, but not
if the developer clones the viewer source repo under a parent directory whose
path itself contains "indra". Fix to handle any number of occurrences.
|
|
|
|
This means that an exception derived from LLContinueError thrown in an
LLEventPump listener won't prevent other listeners on the same LLEventPump
from receiving that event.
|
|
|
|
|
|
|
|
disabled now.
|
|
path containing non-standard characters
|
|
before logging in.
|
|
LLView::childFromPoint(), which is declared to return LLView*, contained a
code path that could 'return false'. This is blatantly wrong. Why has it
compiled on our other compilers so far?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
in the name
|
|
|
|
|
|
|
|
|
|
|
|
|
|
easy URL spoofing.
|
|
|
|
|
|
|
|
|
|
Wrap coroutine call in try/catch in top-level coroutine wrapper function
LLCoros::toplevel(). Distinguish exception classes derived from
LLContinueError (log and continue) from all others (crash with LL_ERRS).
Enhance CRASH_ON_UNHANDLED_EXCEPTIONS() and LOG_UNHANDLED_EXCEPTIONS() macros
to accept a context string to supplement the log message. This lets us replace
many places that called boost::current_exception_diagnostic_information() with
LOG_UNHANDLED_EXCEPTIONS() instead, since the explicit calls were mostly to
log supplemental information.
Provide supplemental information (coroutine name, function parameters) for
some of the previous LOG_UNHANDLED_EXCEPTIONS() calls. This information
duplicates LL_DEBUGS() information at the top of these functions, but in a
typical log file we wouldn't see the LL_DEBUGS() message.
Eliminate a few catch (std::exception e) clauses: the information we get from
boost::current_exception_diagnostic_information() in a catch (...) clause
makes it unnecessary to distinguish.
In a few cases, add a final 'throw;' to a catch (...) clause: having logged
the local context info, propagate the exception to be caught by higher-level
try/catch.
In a couple places, couldn't resist reconciling indentation within a
particular function: tabs where the rest of the function uses tabs, spaces
where the rest of the function uses spaces.
In LLLogin::Impl::loginCoro(), eliminate some confusing comments about an
array of rewritten URIs that date back to a long-deleted implementation.
|
|
overrides DPI compatibility option
|
|
|
|
|
|
since Visual Studio doesn't know __PRETTY_FUNCTION__, and Boost already has a
portable macro to Do The Right Thing.
|
|
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.
|
|
Failure to load an image shouldn't crash the whole viewer.
|
|
|
