Closed Bug 924970 Opened 11 years ago Closed 2 years ago

Assertion failure: mParentSuspended, at dom/workers/WorkerPrivate.cpp:2344

Categories

(Core :: DOM: Workers, defect, P5)

x86
macOS
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: florian, Unassigned)

References

Details

My debug build crashes almost at startup on a profile with Talkilla (https://talkilla.mozillalabs.com/).
I assume the crash happens when the code spawns a real worker from a SocialAPI frameworker.

The stack I get in the Apple crash reporter is:
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   XUL                           	0x0000000102ca006a mozilla::dom::workers::WorkerPrivateParent<mozilla::dom::workers::WorkerPrivate>::SynchronizeAndResume(JSContext*, nsPIDOMWindow*, nsIScriptContext*) + 234 (WorkerPrivate.cpp:2344)
1   XUL                           	0x0000000102c60718 mozilla::dom::workers::RuntimeService::ResumeWorkersForWindow(nsPIDOMWindow*) + 552 (RuntimeService.cpp:1989)
2   XUL                           	0x0000000102c604e5 mozilla::dom::workers::ResumeWorkersForWindow(nsPIDOMWindow*) + 53 (RuntimeService.cpp:1066)
3   XUL                           	0x0000000102a50ce0 nsGlobalWindow::ResumeTimeouts(bool) + 688 (nsGlobalWindow.cpp:11363)
4   XUL                           	0x0000000102a514bc non-virtual thunk to nsGlobalWindow::ResumeTimeouts(bool) + 44 (nsGlobalWindow.cpp:11444)
5   XUL                           	0x000000010244b0ba nsResumeTimeoutsEvent::Run() + 58 (nsXMLHttpRequest.cpp:149)
6   XUL                           	0x0000000104621653 nsThread::ProcessNextEvent(bool, bool*) + 1731 (nsThread.cpp:623)
7   XUL                           	0x000000010457878c NS_ProcessPendingEvents(nsIThread*, unsigned int) + 172 (nsThreadUtils.cpp:188)
8   XUL                           	0x00000001039107ff nsBaseAppShell::NativeEventCallback() + 207 (nsBaseAppShell.cpp:96)
9   XUL                           	0x000000010386b63c nsAppShell::ProcessGeckoEvents(void*) + 428 (nsAppShell.mm:388)
10  com.apple.CoreFoundation      	0x00007fff8b070101 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
11  com.apple.CoreFoundation      	0x00007fff8b06fa25 __CFRunLoopDoSources0 + 245
12  com.apple.CoreFoundation      	0x00007fff8b092dc5 __CFRunLoopRun + 789
13  com.apple.CoreFoundation      	0x00007fff8b0926b2 CFRunLoopRunSpecific + 290
14  com.apple.HIToolbox           	0x00007fff839340a4 RunCurrentEventLoopInMode + 209
15  com.apple.HIToolbox           	0x00007fff83933d84 ReceiveNextEventCommon + 166
16  com.apple.HIToolbox           	0x00007fff83933cd3 BlockUntilNextEventMatchingListInMode + 62
17  com.apple.AppKit              	0x00007fff88dfe613 _DPSNextEvent + 685
18  com.apple.AppKit              	0x00007fff88dfded2 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 128
19  XUL                           	0x0000000103869d87 -[GeckoNSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 119 (nsAppShell.mm:165)
20  com.apple.AppKit              	0x00007fff88df5283 -[NSApplication run] + 517
21  XUL                           	0x000000010386c111 nsAppShell::Run() + 145 (nsAppShell.mm:742)
22  XUL                           	0x00000001034585cc nsAppStartup::Run() + 156 (nsAppStartup.cpp:269)
23  XUL                           	0x000000010157638d XREMain::XRE_mainRun() + 6077 (nsAppRunner.cpp:3868)
24  XUL                           	0x0000000101576b99 XREMain::XRE_main(int, char**, nsXREAppData const*) + 697 (nsAppRunner.cpp:3936)
25  XUL                           	0x0000000101576ffd XRE_main + 77 (nsAppRunner.cpp:4138)
26  org.mozilla.nightlydebug      	0x00000001000022a7 do_main(int, char**, nsIFile*) + 1639 (nsBrowserApp.cpp:275)
27  org.mozilla.nightlydebug      	0x00000001000017e1 main + 321 (nsBrowserApp.cpp:635)
28  org.mozilla.nightlydebug      	0x0000000100001244 start + 52
This is a dup of another bug somewhere... The bug is actually that somewhere in nsGlobalWindow we have a way to call ResumeTimeouts twice on the same window.
Component: DOM: Workers → DOM
How serious is this? Could it be causing the crashes in bug 924525?
We should just make this assertion non-fatal until the underlying issue is fixed.
Although ekr tried that and ran into crashes elsewhere so ...
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #5)
> Although ekr tried that and ran into crashes elsewhere so ...

I commented out 3 mParentSuspended assertions in WorkerPrivate.cpp and then my debug build crashed with the same stack as nightlies do in bug 924525.
Commenting out assertions is almost never going to work ;)

We could just make Resume/Suspend no-ops if we're already resumed/suspended. It just hides the real logic error in nsGlobalWindow though.
(In reply to ben turner [:bent] (needinfo? encouraged) from comment #7)
> Commenting out assertions is almost never going to work ;)

In this case it actually works. If I also build with a fix for bug 924525, my debug build is stable.
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.
Priority: -- → P5
Component: DOM → DOM: Core & HTML
QA Whiteboard: qa-not-actionable
Component: DOM: Core & HTML → DOM: Workers

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Severity: critical → --

The assert which was observed in has been removed and the bug has therefore become fixed.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.