Don't print stack trace when running under a debugger
Categories
(Testing :: Reftest, defect, P3)
Tracking
(Not tracked)
People
(Reporter: MatsPalmgren_bugz, Unassigned)
References
Details
I'm running:
./mach reftest --debugger=rr layout/reftests/bidi/1161752.html
I have a local change that makes that test trigger a fatal assertion, which results in:
Initializing stack-fixing for the first stack frame, this may take a while...
... a stack dump ...
This is not what I want. I want an actual crash dump that I can debug it with rr.
I can see from the log that firefox is run under rr, so it appears that mach recognizes the --debugger argument correctly. But there's some crash handler that doesn't seem to recognize that the process is running under a debugger...
When I run rr ps I see that all processes exited with exit code 0. This is bad. A fatal assertion should produce a non-zero exit code.
|
Reporter | |
Comment 1•4 years ago
|
||
Is there a workaround for this?
Can I set some environment variable to disable the crash handler that prints stack traces?
Can I set some .mozconfig option to disable that code altogether? (I want actual crash dumps)
|
||
Comment 2•4 years ago
|
||
Looks like the --debugger argument and its associated behaviour is defined by the reftest command.
I'm not sure how you can adjust it's behaviour, so I'm going to defer to the reftest folks :)
If this does turn out to be mach-specific, feel free to punt this ticket back to us build folks and I'll do some investigation.
|
||
Comment 3•4 years ago
|
||
I can't reproduce, FWIW. Here's what I did:
- Patched nsBidi.cpp to MOZ_ASSERT(0).
- Built with --enable-debug
- Ran the command from comment 0
During the run, I do see
Assertion failure: 0, at /tmp/gecko/layout/base/nsBidi.cpp:21
Initializing stack-fixing for the first stack frame, this may take a while...
followed with a stack trace.
In the resulting rr trace, there is a process with exit code -11.
So to me, there is no bug here. What looks buggy to me is
- I had to ctrl+c because it got stuck waiting for whatever after that
- when not running under a debugger, I can see both a fix-stack'ed stack from the MOZ_ASSERT and a crash dump (from minidump_stackwalk) that lacks symbols because we don't build breakpad symbol files, and the latter shouldn't be displayed.
|
||
Comment 4•4 years ago
|
||
Looks like there is some code in
layout/tools/reftest/reftestcommandline.py
layout/tools/reftest/runreftest.py
to handle the debugger argument, not very familiar with these files myself, I guess that code differs from other code in our tree for handler the --debugger argument (like say for mochitest)?
Description
•