| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Raw lllog() doesn't work for varying log level, which is why LL_VLOGS()
exists.
|
|
|
|
In some places we want to log the same information but with different severity
depending on specifics. In other cases we need to test the availability of the
logging subsystem before engaging it. LL_VLOGS() accepts an LLError::ELevel
argument that can differ with each call, while retaining the desirable feature
of deciding only once for each level.
|
|
|
|
|
|
|
|
independently of general Snapshot floater
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
near the end of LLAppViewer::cleanup() so every LLSingleton class that hasn't
already been explicitly cleaned up gets a chance to perform its own cleanup.
|
|
|
|
for consistency with everything else, so we can use SUBSYSTEM_CLEANUP() macro
to call it.
|
|
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.
|
|
|
|
|
|
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?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
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.
|
