On Mac, even if you run a test program with --debug or set LOGTEST=DEBUG, it
won't log to stderr if you're filtering build output or running the build in
an emacs compile buffer. This is because, on Mac, a viewer launched by mouse
rather than from the command line is passed a stderr stream that ultimately
gets logged to the system Console. The shouldLogToStderr() function is
intended to avoid spamming the Console with the (voluminous) viewer log
output. It tests whether stderr isatty() and, if not, suppresses calling
LLError::logToStderr().
This makes debugging test programs using log output trickier than necessary.
Change shouldLogToStderr() to permit logging when either stderr isatty() or is
a pipe. The original intention is preserved in that empirically, a viewer
launched by mouse is passed a stderr stream identified as a character device
rather than as a pipe.
Also introduce SetEnv, a class that facilitates setting (e.g.) LOGTEST=DEBUG
for specific test programs without setting it for all test programs in the
build. Using the constructor for a static object means you can set environment
variables before main() is entered, which is important because it's the main()
function in test.cpp that acts on the LOGTEST and LOGFAIL environment
variables.
These changes make it unnecessary to retain the temporary change in test.cpp
to force LOGTEST to DEBUG.
LLStacktrace has no behavior except when you stream an instance to a
std::ostream. Then it reports the current traceback at that point to the
ostream.
This bit of indirection is intended to avoid the boost/stacktrace.hpp header
from being included everywhere.
LLSD::emptyMap() is a factory for an empty map instance, NOT a predicate on
any particular instance. In fact checking configuration.isUndefined() and
testing whether the map is empty are both subsumed by (! configuration).
Make the LLError::Settings LLSingleton duplicate the file handle for stderr
(usually 2) on construction. Make its destructor restore the original target
for that file handle. Provide a getDupStderr() method to obtain the duplicate
file handle.
Move Settings declaration up to the top of the file so other code can
reference it.
Make RecordToFile (the Recorder subclass engaged by LLError::logToFile()),
instead of duplicating stderr's file handle itself, capture the duplicate
stderr file handle from Settings to revert stderr redirection on destruction.
Make RecordToStderr (the Recorder subclass engaged by LLError::logToStderr())
use fdopen() to create an LLFILE* targeting the duplicate file handle from
Settings. Write output to that instead of to stderr so logToStderr() continues
to provide output for the user instead of duplicating each line into the log
file.
Some of the libraries we use produce log output to stderr. Such output can be
informative, but is invisible unless you launch the viewer from a console. In
particular, it's invisible to anyone trying to diagnose a problem by reading
someone else's SecondLife.log file.
Make RecordToFile -- the Recorder subclass engaged by LLError::logToFile() --
redirect STDERR_FILENO to the newly-opened log file so that any subsequent
writes to stderr (or cerr, for that matter) will be captured in the log file.
But first duplicate the original stderr file handle, and restore it when
RecordToFile is destroyed. That way, output written to stderr during the final
moments of application shutdown should still appear on (console) stderr.
The comments within indra/test/test.cpp promise that --debug is, in fact, like
LOGTEST=DEBUG. Until now, that was a lie. LOGTEST=level displayed log output
on stderr as well as in testprogram.log, while --debug did not.
Add LLError::logToStderr() function, and make initForApplication() (i.e.
commonInit()) call that instead of instantiating RecordToStderr inline. Also
call it when test.cpp recognizes --debug switch.
Remove the mFileRecorder, mFixedBufferRecorder and mFileRecorderFileName
members from SettingsConfig. That tactic doesn't scale.
Instead, add findRecorder<RECORDER>() and removeRecorder<RECORDER>() template
functions to locate (or remove) a RecorderPtr to an object of the specified
subclass. Both are based on an underlying findRecorderPos<RECORDER>() template
function. Since we never expect to manage more than a handful of RecorderPtrs,
and since access to the deleted members is very much application setup rather
than any kind of ongoing access, a search loop suffices.
logToFile() uses removeRecorder<RecordToFile>() rather than removing
mFileRecorder (the only use of mFileRecorder).
logToFixedBuffer() uses removeRecorder<RecordToFixedBuffer>() rather than
removing mFixedBufferRecorder (the only use of mFixedBufferRecorder).
Make RecordToFile store the filename with which it was instantiated. Add a
getFilename() method to retrieve it. logFileName() is now based on
findRecorder<RecordToFile>() instead of mFileRecorderFileName (the only use of
mFileRecorderFileName).
Make RecordToStderr::mUseANSI a simple bool rather than a three-state enum,
and set it immediately on construction. Apparently the reason it was set
lazily was because it consults its own checkANSI() method, and of course
'this' doesn't acquire the leaf class type until the constructor has completed
successfully. But since nothing in checkANSI() depends on anything else in
RecordToStderr, making it static solves that problem.
Use function-static LLMutex instances instead of module-static instances,
since some log calls are evidently issued before we get around to initializing
llerror.cpp module-static variables.
The Windows implementation of demangle() assumed that a "mangled" class name
produced by typeid(class).name() always starts with the prefix "class ",
checked for that and removed it. If the mangled name didn't start with that
prefix, it would emit a debug message and return the full name.
When the class in question is actually a struct, the prefix is "struct "
instead. But when demangle() was being called before logging had been fully
initialized, the debug message remarking that it didn't start with "class "
crashed.
Look for either "class " or "struct " prefix. Remove whichever is found and
return the rest of the name. If neither is found, only log if logging is
available.
Silence nagging about running launcher for non-release for download builds.
Tweak newview CMake to use executable instead of SL_Launcher and
re-enable debugging within Xcode.
The logging subsystem depends on two different LLSingletons for some reason.
It turns out to be very difficult to completely avoid executing any logging
calls after the LLSingletonBase::deleteAll(), but we really don't want to
resurrect those LLSingletons so late in the run for a couple stragglers.
Introduce LLSingleton::wasDeleted() query method, and use it in logging
subsystem to simply bypass last-millisecond logging requests.
Nat Goodspeed