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

avoid taking a minidump when debugger is not present for breakpoint() on Windows

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.3.2
    • Component/s: Internal Code
    • Labels:
      None
    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Linked BF Score:
      0

      Description

      When breakpoint() is called in a debug build (e.g. for an fassertFailedNoTrace), it calls DebugBreak() on Windows. This throws an EXCEPTION_BREAKPOINT exception that is caught by a debugger if present. If no debugger is present, the exception is caught by the top level handler and transfers control to our unhandled exception handler. This handler prints a stack trace and begins a minidump.

      Meanwhile, if this is process is signaled to stop, another thread can start the shutdown process while the minidump is working. For example, the process can be signaled to stop by a shell that has spawned the process and is waiting for a certain message to appear in the log as a result of triggering the fassert. This thread can commonly hit an access violation or stack overflow error, and the exit status of the process reflects those HRESULTs.
      This appears to be the issue in BF-1843 and others.

        Attachments

          Activity

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: