Closed Bug 919467 Opened 6 years ago Closed 6 years ago

Dig into why browser_thumbnail_background_crash test is disabled on ASan builds

Categories

(Firefox :: General, defect)

defect
Not set

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: markh, Assigned: markh)

Details

Bug 919438 disabled the test on ASan builds, but the symptoms weren't purely crashreporter related - it was as though we never saw the child process crash.  If true, it might point to some e10s specific issue.

http://mxr.mozilla.org/mozilla-central/source/dom/ipc/tests/test_process_error.xul would, at first glance, imply it should have a similar problem, but it uses an observer for child "termination" rather than child "crash", and on IRC:

markh: decoder: no, I suspect it's some edge-case interation with e10s child process and asan
decoder: oh ok. in asan you wont crash at all btw. the process will exit
decoder: but not with a signal
decoder: in case thats somehow relevant

Taking the bug, but anyone is welcome to it :)
I don't know much about e10s but if there's one observer for "termination" and one for "crash", then I would guess ASan only works with the "termination" one. Even on a regular SIGSEGV, ASan will catch the signal, spill out a trace on stderr, and then regularly exit with exit code 1. No signals are propagated, so it's not visible as a crash to the parent process.
hrm - so yeah, the correct solution is probably:

* if no MOZ_CRASHREPORTER, the test should still run and pass but not see crash details - so it can just skip the assertion about seeing 2 crashdumps.

* if MOZ_ASAN is defined, we need to skip the test entirely - neither the runtime nor the test will see a crash.
Bug 934207 re-enabled this test unconditionally and I've confirmed it appears in recent ASan b-c test logs, so there's nothing to do here.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.