Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-82658

Log system will attempt to allocate inside of signal handler

    • Type: Icon: Bug Bug
    • Resolution: Unresolved
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • None
    • Service Arch
    • ALL
    • N&O Prioritized List

      The signal handling code uses a special ostream that avoids allocating when we collect stacktraces/unwind the stack when handling a fatal signal, like SIGSEGV. This is because it is unsafe to call malloc from within a signal handler; it is not an async-signal-safe function. It is further dangerous because, if we are handling SIGSEGV and the heap state is already corrupted, we are more likely to encounter another SIGSEGV when attempting to access to allocator/heap again, possibly resulting in a fatal deadlock.

      However, the boost::logging infrastructure we rely on will itself try and allocate when we go to dump out the ostream we've collected (Containing the stack trace) to the log. This can result in all the unsafe behavior discussed above, and could prevent the stacktrace from being logged and the process from exiting until it is forcefully killed.

            Assignee:
            backlog-server-servicearch [DO NOT USE] Backlog - Service Architecture
            Reporter:
            george.wangensteen@mongodb.com George Wangensteen
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated: