801849 - Assertion failure: "nsDOMMutationObserver not thread-safe" after crashinject

Status: NEW

(Core :: XPCOM, defect)

Description

[Jesse Ruderman]

Attachment: fuzz log tail

What kind of code would be running after crashinject starts affecting the process? Does this sequence of events make sense?  (Seems to only happen on Windows, fwiw.)

1. DOM fuzzer sets up an infinite loop: a MutationObserver that adds a stylesheet
2. automation.py decides Firefox has timed out
3. automation.py takes a screenshot
4. automation.py runs crashinject.exe
5. [!!!] Assertion failure: _mOwningThread.GetThread() == PR_GetCurrentThread() (nsDOMMutationObserver not thread-safe), at e:/builds/moz2_slave/m-cen-w32-dbg/build/content/base/src/nsDOMMutationObserver.cpp:401
6. Breakpad shows a crash that does not have the assertion from (5) at the top, but does have Mutation Observer code deep in the main thread's stack.

Is the same kind of thing going on in bug 795783?

Comment 1

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

crashinject will run C++ static dtors when it calls exit(whatever), and those dtors will run on the crashinject thread.  This is the same type of issue as bug 795783.  I would suspect http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsDOMMutationObserver.cpp#696.

Comment 2

[(not currently active) Ted Mielczarek]

Interesting. I wonder if we should stop doing crashinject, and instead just build a binary that calls MinidumpWriteDump directly on the Firefox process and then terminates it?

Comment 3

[Jesse Ruderman]

Could crashinject do something other than exit(), so it doesn't cause static dtors to run?