Seen on current trunk on leo. Looking for STR but basically what I did was opening radio, marketplace and twitter. Also trying to get a stack in gdb. bent, how bad is this?

We've seen this elsewhere in intermittents on tbpl.

I think I found a STR: Download the Line app and start: Program received signal SIGSEGV, Segmentation fault. 0x413bb010 in mozilla::dom::workers::WorkerPrivateParent<mozilla::dom::workers::WorkerPrivate>::SynchronizeAndResume (this=0x4606c800, aCx=0x404b6c60, aWindow=0x443e8150, aScriptContext=0x445f6b80) at /Volumes/mac/moz/ib2g/dom/workers/WorkerPrivate.cpp:2567 2567 MOZ_ASSERT_IF(IsDedicatedWorker(), mParentSuspended); (gdb) bt #0 0x413bb010 in mozilla::dom::workers::WorkerPrivateParent<mozilla::dom::workers::WorkerPrivate>::SynchronizeAndResume ( this=0x4606c800, aCx=0x404b6c60, aWindow=0x443e8150, aScriptContext=0x445f6b80) at /Volumes/mac/moz/ib2g/dom/workers/WorkerPrivate.cpp:2567 #1 0x413a647e in mozilla::dom::workers::RuntimeService::ResumeWorkersForWindow (this=<value optimized out>, aWindow=0x443e8150) at /Volumes/mac/moz/ib2g/dom/workers/RuntimeService.cpp:2073 #2 0x413a64f2 in mozilla::dom::workers::ResumeWorkersForWindow (aWindow=0x443e8150) at /Volumes/mac/moz/ib2g/dom/workers/RuntimeService.cpp:1140 #3 0x4122d79e in nsGlobalWindow::ResumeTimeouts (this=0x443e8140, aThawChildren=<value optimized out>) at /Volumes/mac/moz/ib2g/dom/base/nsGlobalWindow.cpp:12598 #4 0x41512022 in nsResumeTimeoutsEvent::Run (this=<value optimized out>) at /Volumes/mac/moz/ib2g/content/base/src/nsXMLHttpRequest.cpp:148 #5 0x40812c9c in nsThread::ProcessNextEvent (this=0x40422780, mayWait=false, result=0xbebf3e17) at /Volumes/mac/moz/ib2g/xpcom/threads/nsThread.cpp:643 #6 0x407c4100 in NS_ProcessNextEvent (thread=0x40422780, mayWait=false) at /Volumes/mac/moz/ib2g/xpcom/glue/nsThreadUtils.cpp:263 #7 0x409d72c2 in mozilla::ipc::MessagePump::Run (this=0x40401b50, aDelegate=0xbebf48d4) at /Volumes/mac/moz/ib2g/ipc/glue/MessagePump.cpp:95 #8 0x409d7442 in mozilla::ipc::MessagePumpForChildProcess::Run (this=0x40401b50, aDelegate=0xbebf48d4) at /Volumes/mac/moz/ib2g/ipc/glue/MessagePump.cpp:283 #9 0x409c2e0e in MessageLoop::RunInternal (this=0xbebf48d4) at /Volumes/mac/moz/ib2g/ipc/chromium/src/base/message_loop.cc:226 #10 0x409c2e26 in MessageLoop::RunHandler (this=0xbebf48d4) at /Volumes/mac/moz/ib2g/ipc/chromium/src/base/message_loop.cc:219 #11 MessageLoop::Run (this=0xbebf48d4) at /Volumes/mac/moz/ib2g/ipc/chromium/src/base/message_loop.cc:193 #12 0x4115114e in nsBaseAppShell::Run (this=0x4437b5e0) at /Volumes/mac/moz/ib2g/widget/xpwidgets/nsBaseAppShell.cpp:164 #13 0x41b1404e in XRE_RunAppShell () at /Volumes/mac/moz/ib2g/toolkit/xre/nsEmbedFunctions.cpp:679 #14 0x409d744e in mozilla::ipc::MessagePumpForChildProcess::Run (this=0x40401b50, aDelegate=0xbebf48d4) at /Volumes/mac/moz/ib2g/ipc/glue/MessagePump.cpp:253 #15 0x409c2e0e in MessageLoop::RunInternal (this=0xbebf48d4) at /Volumes/mac/moz/ib2g/ipc/chromium/src/base/message_loop.cc:226 #16 0x409c2e26 in MessageLoop::RunHandler (this=0xbebf48d4) at /Volumes/mac/moz/ib2g/ipc/chromium/src/base/message_loop.cc:219 #17 MessageLoop::Run (this=0xbebf48d4) at /Volumes/mac/moz/ib2g/ipc/chromium/src/base/message_loop.cc:193 #18 0x41b148d0 in XRE_InitChildProcess (aArgc=2, aArgv=0xbebf49e4, aProcess=3200207476) at /Volumes/mac/moz/ib2g/toolkit/xre/nsEmbedFunctions.cpp:516 #19 0x00008894 in main (argc=6, argv=0xbebf4a74) at /Volumes/mac/moz/ib2g/ipc/app/MozillaRuntimeMain.cpp:149

So what's going on here is that the worker is created during a sync XHR (presumably during one of the event callbacks). It's mParentSuspended flag is thus born out of sync with the parent, and when we try to resume the window we assert about that.

Let's make this MOZ_CRASH to teach sync XHR folks a lesson.

This issue is 100% reproducible with pdf.js test suite using a debug build.

Andrew, this is causing some startup crashes for the homescreen in debug mode. Can you help out here?

We end up in an endless loop starting the homescreen. So I can't do serious testing with debug mode :(

Talking with khuey, he suggested to remove the asserts. This seems to be an easy fix. But he also told me that bent has some ideas about this issue. I'm happy to work on this issue, but before I want to know bent's thought.

Simply removing that one assert won't cut it, but you could probably just do an early return if mParentSuspended is true. The medium-term fix is to change the connection between a window "freezing" (timeouts not running) with whether workers are running or not.

(In reply to ben turner [:bent] (use the needinfo? flag!) from comment #11) > The medium-term fix is to change the connection between a window "freezing" > (timeouts not running) with whether workers are running or not. Eddy was looking at that, IIRC.

Your test has been integrated in the patch.

(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #12) > (In reply to ben turner [:bent] (use the needinfo? flag!) from comment #11) > > The medium-term fix is to change the connection between a window "freezing" > > (timeouts not running) with whether workers are running or not. > > Eddy was looking at that, IIRC. I have a patch in the pipeline for this as part of bug 757133. I haven't put it up for review yet since I have a bunch of other patches that need to be r+'d first.

Comment on attachment 8509408 [details] [diff] [review] parent.patch Review of attachment 8509408 [details] [diff] [review]: ----------------------------------------------------------------- Update the author and commit message please.