1350566 - Crash in mozilla::ipc::MessageChannel::AssertWorkerThread | mozilla::ipc::MessageChannel::CxxStackFrame::CxxStackFrame | mozilla::ipc::MessageChannel::Send | mozilla::layers::PAPZCTreeManagerChild::SendUpdateZoomConstraints

Status: RESOLVED WORKSFORME

(Core :: Layout, defect, P3)

Description

[Calixte Denizet (:calixte)]

This bug was filed from the Socorro interface and is 
report bp-1e5f3fc5-053f-4ae6-9a3c-03b132170325.
=============================================================

There are 2 crashes on nightly 55 with buildid 20170324030205. In analyzing the backtrace, the regression may have been introduced by patch [1] to fix bug 1342863.

[1] https://hg.mozilla.org/mozilla-central/rev?node=2f76caec4138c58f2be6314e9d41b58f7a5cb06e

Comment 1

[Tommy Kuo (away forever...)]

I'll take a look!

Comment 2

[Tommy Kuo (away forever...)]

Hi Bevis, I read the crash report. It crashed on `MOZ_RELEASE_ASSERT(mWorkerLoopID == MessageLoop::current()->id()) (not on worker thread!)`.

In my patch[1], I replaced `NS_DispatchToMainThread()` by `mDocument->Dispatch()`. AFAIK, `nsDocument::Dispatch()` also dispatches event to the main thread. Do you know any case make it dispatch to the wrong thread?

[1]: https://hg.mozilla.org/mozilla-central/rev?node=2f76caec4138c58f2be6314e9d41b58f7a5cb06e

Comment 3

[Bevis Tseng[:bevis][:btseng](Exited)]

No, nsDocument::Dispatch() always dispatch the runnables to the main thread:
http://searchfox.org/mozilla-central/source/xpcom/threads/Dispatcher.cpp#129-133

From the call stack, it seems that the "ZoomConstraintsClient::RefreshZoomConstraints" was called directly by  	mozilla::PresShell::ResizeReflow() instead of the runnable you dispatched in bug 1342863.

It's more likely that the call sequence of PAPZCTreeManagerChild::SendUpdateZoomConstraints() was triggered from an unexpected thread instead.

Comment 4

[Kartikaya Gupta (email:[e-mail])]

I'm fairly sure this isn't actually a threading problem, but the IPC channel is getting closed. That AssertWorkerThread function is just how it manifests.

Comment 6

[Kartikaya Gupta (email:[e-mail])]

Per the discussion in bug 1415610 this is probably happening as a result of GPU process crashes. As such we shouldn't be crashing the content process but should recover gracefully from this scenario. Either mApzcTreeManager in TabChild needs to be nulled out as a result of the GPU process crash handling, or we should be checking to see if the IPC channel is still ok before sending.

Comment 7

[Julien Cristau [:jcristau]]

Jim what is the next step on this to follow up on comment 6?

Comment 8

[Jim Mathies [:jimm]]

(In reply to Julien Cristau [:jcristau] from comment #7)
> Jim what is the next step on this to follow up on comment 6?

We'll try to find some time to work on this. This is very low volume btw.

Comment 9

[Liz Henry (:lizzard) (relman/hg->git project)]

It looks like this was fixed or the signatures shifted, as there aren't any crashes showing up past Firefox 57.0.2.