[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: |
|
||||
| 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. |
| 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: |
| 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. |
| 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. |