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)
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 ...
Reporter | ||
Comment 6•11 years ago
|
||
(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.
Reporter | ||
Comment 8•11 years ago
|
||
(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.
Comment 9•6 years ago
|
||
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
Assignee | ||
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
Updated•2 years ago
|
Component: DOM: Core & HTML → DOM: Workers
Comment 10•2 years ago
|
||
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 → --
Comment 11•2 years ago
|
||
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.
Description
•