551860 - Don't break on NS_DebugBreak(NS_DEBUG_ABORT, ...)

Status: RESOLVED FIXED

(Core :: XPCOM, defect)

Description

[Karl Tomlinson (:karlt)]

On POSIX system, raising a break point while not under a debugger terminates
the process immediately.  This circumvents the signal handlers in
nsSigHandlers.cpp installed on Linux to give time to attach a debugger.
It also means that the stack doesn't get reported.

Even if a debugger is attached, the break point doesn't really add anything
because the debugger will usually catch the SIGABRT anyway.

Comment 1

[Karl Tomlinson (:karlt)]

Attachment: patch

At the time that the trace trap was added in
http://hg.mozilla.org/mozilla-central/rev/b105843e4df3 and
http://hg.mozilla.org/mozilla-central/rev/245eec6c6d84,
::Abort(const char*) would raise(SIGABRT) ifdef _WIN32.  Apparently that
didn't trigger an attach-debugger dialog, but ::DebugBreak() does.  Abort has
since been modified in bug 534922 and now does TouchBadMemory() to induce a
SIGSEGV.  I guess SIGSEGV might behave similarly to SIGABRT and so
::DebugBreak() might still be helpful on that platform.

Comment 2

[Karl Tomlinson (:karlt)]

http://hg.mozilla.org/mozilla-central/rev/6fa3d6bd940c

Comment 3

[[e-mail]]

(In reply to comment #1)
> ::Abort(const char*) would raise(SIGABRT) ifdef _WIN32.  Apparently that
> didn't trigger an attach-debugger dialog, but ::DebugBreak() does.
Correct. Instead raise(SIGABRT) shows a dialog "This application has requested the Runtime to terminate it in an unusual way." and exits.

> Abort has since been modified in bug 534922 and now does TouchBadMemory() to
> induce a SIGSEGV.  I guess SIGSEGV might behave similarly to SIGABRT and so
> ::DebugBreak() might still be helpful on that platform.
Actually the real reason ::DebugBreak is helpful is that (in your debugger) you can simply hit Go to continue from a breakpoint instruction.