919467 - Dig into why browser_thumbnail_background_crash test is disabled on ASan builds

Status: RESOLVED WORKSFORME

(Firefox :: General, defect)

Description

[Mark Hammond [:markh] [:mhammond]]

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 :)

Comment 1

[Christian Holler (:decoder)]

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.

Comment 2

[Mark Hammond [:markh] [:mhammond]]

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.

Comment 3

[Mark Hammond [:markh] [:mhammond]]

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.