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•5 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
•