[SERVER-22699] avoid taking a minidump when debugger is not present for breakpoint() on Windows Created: 17/Feb/16  Updated: 22/Feb/16  Resolved: 17/Feb/16

Status: Closed
Project: Core Server
Component/s: Internal Code
Affects Version/s: None
Fix Version/s: 3.3.2

Type: Bug Priority: Major - P3
Reporter: Eric Milkie Assignee: Eric Milkie
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Backwards Compatibility: Fully Compatible
Operating System: ALL
Participants:
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.



 Comments   
Comment by Githook User [ 17/Feb/16 ]

Author:

{u'username': u'milkie', u'name': u'Eric Milkie', u'email': u'milkie@10gen.com'}

Message: SERVER-22699 avoid taking a minidump when debugger is not present for breakpoint() on Windows
Branch: master
https://github.com/mongodb/mongo/commit/f5fd9b3328cfa07c6a5d4f296bbaf6c3d0c3946b

Comment by Eric Milkie [ 17/Feb/16 ]

But fasserts already call std::abort(), which should trigger a minidump irrespective of having called breakpoint() (and it works in release builds too!). I'm more concerned about issues with fassertFailedNoTrace, which we use to abort the server but the reason is typically known, so we don't need to print a stack trace or dump the core.
I do notice that fassertFailedWithStatus() doesn't call abort, it calls quickExit, which is incorrect. invariantOKFailed() is also incorrect. But the others appear to be correct.

Comment by Mark Benvenuto [ 17/Feb/16 ]

The only way for me to understand failures in MemoryMappedFile::remapPrivateView which triggers a fassert is with a memory dump. See BF-1760 as an example.

Generated at Thu Feb 08 04:01:12 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.