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.