Closed Bug 1350566 Opened 8 years ago Closed 7 years ago

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

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Platform:
Unspecified
All
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox55 --- wontfix
firefox56 --- wontfix
firefox57 --- wontfix
firefox58 --- unaffected
firefox59 --- unaffected

People

(Reporter: calixte, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: crash, regression, Whiteboard: [clouseau])

Crash Data

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
Flags: needinfo?(kuoe0)
I'll take a look!
Flags: needinfo?(kuoe0)
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
Flags: needinfo?(btseng)
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.
Flags: needinfo?(btseng)
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.
Crash Signature: [@ mozilla::ipc::MessageChannel::AssertWorkerThread | mozilla::ipc::MessageChannel::CxxStackFrame::CxxStackFrame | mozilla::ipc::MessageChannel::Send | mozilla::layers::PAPZCTreeManagerChild::SendUpdateZoomConstraints] → [@ mozilla::ipc::MessageChannel::AssertWorkerThread | mozilla::ipc::MessageChannel::CxxStackFrame::CxxStackFrame | mozilla::ipc::MessageChannel::Send | mozilla::layers::PAPZCTreeManagerChild::SendUpdateZoomConstraints] [@ mozilla::ipc::MessageChannel::Se…
Version: 52 Branch → Trunk
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.
status-firefox56: --- → affected
status-firefox57: --- → affected
status-firefox58: --- → affected
OS: Windows 8 → All
Jim what is the next step on this to follow up on comment 6?
status-firefox55: fix-optional → wontfix
status-firefox56: affected → wontfix
status-firefox57: affected → wontfix
status-firefox58: affected → fix-optional
Flags: needinfo?(jmathies)
Crash Signature: mozilla::ipc::MessageChannel::Send | mozilla::layers::PAPZCTreeManagerChild::SendUpdateZoomConstraints ] → mozilla::ipc::MessageChannel::Send | mozilla::layers::PAPZCTreeManagerChild::SendUpdateZoomConstraints ] [@ mozilla::ipc::MessageChannel::Send | mozilla::layers::PAPZCTreeManagerChild::SendUpdateZoomConstraints ]
status-firefox59: --- → affected
(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.
Flags: needinfo?(jmathies)
Priority: -- → P3
It looks like this was fixed or the signatures shifted, as there aren't any crashes showing up past Firefox 57.0.2.
Status: NEW → RESOLVED
Closed: 7 years ago
status-firefox58: fix-optional → unaffected
status-firefox59: affected → unaffected
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.