Skip to content
Snippets Groups Projects
  1. Sep 29, 2020
  2. Sep 28, 2020
  3. Sep 25, 2020
  4. Sep 08, 2020
  5. Aug 28, 2020
  6. Aug 24, 2020
  7. Jul 27, 2020
  8. Jul 26, 2020
  9. Jul 21, 2020
  10. Jul 20, 2020
  11. Jul 07, 2020
  12. Jul 01, 2020
  13. Apr 03, 2020
    • Nat Goodspeed's avatar
      DRTVWR-476: Facilitate debugging test programs with logging. · 962ccb4f
      Nat Goodspeed authored
      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.
      962ccb4f
  14. Mar 25, 2020
    • Nat Goodspeed's avatar
      DRTVWR-476: Introduce LLStacktrace, a token to stream stack trace. · cc9bdbcf
      Nat Goodspeed authored
      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.
      cc9bdbcf
    • Nat Goodspeed's avatar
    • Nat Goodspeed's avatar
    • Nat Goodspeed's avatar
    • Nat Goodspeed's avatar
      DRTVWR-476: Partially revert 978e09882565: undo using LLTempRedirect. · 950204a5
      Nat Goodspeed authored
      But leave LLTempRedirect available in the code base.
      950204a5
    • Nat Goodspeed's avatar
      DRTVWR-476: Don't test configuration.emptyMap(). · 7ef10fe1
      Nat Goodspeed authored
      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).
      7ef10fe1
    • Nat Goodspeed's avatar
    • Nat Goodspeed's avatar
      7f1a2002
    • Nat Goodspeed's avatar
      DRTVWR-476: Try to extend stderr redirection to Windows as well. · 07134aae
      Nat Goodspeed authored
      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.
      07134aae
    • Nat Goodspeed's avatar
      DRTVWR-476: Try to log stderr output from classic-C libraries. · 7845f73c
      Nat Goodspeed authored
      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.
      7845f73c
    • Nat Goodspeed's avatar
      DRTVWR-476: Make test program --debug switch work like LOGTEST=DEBUG. · 6b70493d
      Nat Goodspeed authored
      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.
      6b70493d
    • Brad Kittenbrink's avatar
      Fixed variadic macro usage in LL_ERRS_IF and LL_WARNS_IF and improved... · a6f31e91
      Brad Kittenbrink authored
      Fixed variadic macro usage in LL_ERRS_IF and LL_WARNS_IF and improved LLError::shouldLogToStderr() behavior under xcode.
      a6f31e91
    • Nat Goodspeed's avatar
      DRTVWR-494: Get initialized LLMutexes for very early log calls. · 4c9e90de
      Nat Goodspeed authored
      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.
      4c9e90de
    • Nat Goodspeed's avatar
      DRTVWR-494: Fix VS LLError::Log::demangle() vulnerability. · 1fc7c994
      Nat Goodspeed authored
      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.
      1fc7c994
  15. Mar 19, 2020
  16. Jul 30, 2019
  17. Jan 14, 2019
  18. Nov 29, 2018
  19. Oct 11, 2018
  20. Sep 26, 2018
  21. Sep 19, 2018
  22. Sep 07, 2018
Loading