1276853 - Crash in mozilla::CycleCollectedJSRuntime::ProcessMetastableStateQueue

Status: RESOLVED DUPLICATE of bug 1235183

(Core :: XPCOM, defect)

Description

[Nicholas Nethercote [inactive]]

This bug was filed from the Socorro interface and is 
report bp-aa453ce4-bb48-4603-8302-617102160524.
=============================================================

We have 600+ crashes in the past week because the MOZ_RELEASE_ASSERT(!mDoingStableStates) assertion is failing.

khuey, can you please investigate?

Comment 1

[Boris Zbarsky [:bzbarsky]]

The incident linked above is not super-helpful, but https://crash-stats.mozilla.com/report/index/eb5580b6-ea44-4cc7-9b70-19f792160524 is much more so, I think.  That stack at least shows actual reentry...

In that stack, CycleCollectedJSRuntime::ProcessStableStateQueue calls ImageLoadTask::Run which tries to do an image load.  After wending its way through necko for a bit, we do HttpBaseChannel::CallOnModifyRequestObservers.  Now we're off to "random script in extensions" land.  That extension script does various stuff, then we have NS_InvokeByIndex calling nsThread::ProcessNextEvent: the extension decided to spin the event loop, so cute.  And now we lose, because we reenter and attempt to do stable queue processing.

Even if the extension didn't manually spin the event loop, it could end up doing a sync XHR or whatnot, which would have the same effect.

Anyway, the right fix here is some variant of bug 893916 or something: we do not want to be doing AsyncOpen sync from the stable state queue.

Another option would be to have necko do all its notifications async from the AsyncOpen() caller.  That wouldn't solve the performance issues from bug 893916, but would fix the reentry stuff, at least.

Comment 2

[Boris Zbarsky [:bzbarsky]]

I spot-checked other stacks at https://crash-stats.mozilla.com/search/?product=Firefox&moz_crash_reason=%3DMOZ_RELEASE_ASSERT%28%21mDoingStableStates%29&_facets=moz_crash_reason&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=moz_crash_reason#crash-reports and the ones that are not obviously cut off all seem to have necko notifying observers on the stack above the assertion point.  Some of them are then cut off before they show the necko entrypoint.

Comment 3

[Nicholas Nethercote [inactive]]

My needinfo request for khuey failed because he's not accepting requests at the moment. But I might as well CC him...