Closed Bug 766883 Opened 8 years ago Closed 7 years ago
Mac OS X debug build crashes with "ABORT: Tracer synchronization state is wrong" at shutdown
I'm seeing this frequently with my local debug build of mozilla-central on OS X. It'll often happen if I just launch the browser (from the Terminal command line), wait for the window to display, and then quit. It doesn't happen every time, though; perhaps there's some kind of a race or other timing-sensitive issue? ###!!! ABORT: Tracer synchronization state is wrong: '!sTracerProcessed', file /Users/jkew/mozdev/mozilla-central/widget/cocoa/WidgetTraceEvent.mm, line 47 mozilla::SignalTracerThread()+0x000000A0 [/Users/jkew/mozdev/mozilla-central/obj-ff-dbg/dist/NightlyDebug.app/Contents/MacOS/XUL +0x01634496] mozilla::ShutdownEventTracing()+0x0000001C [/Users/jkew/mozdev/mozilla-central/obj-ff-dbg/dist/NightlyDebug.app/Contents/MacOS/XUL +0x000211D0] XREMain::XRE_main(int, char**, nsXREAppData const*)+0x00000220 [/Users/jkew/mozdev/mozilla-central/obj-ff-dbg/dist/NightlyDebug.app/Contents/MacOS/XUL +0x00010446] XRE_main+0x00000062 [/Users/jkew/mozdev/mozilla-central/obj-ff-dbg/dist/NightlyDebug.app/Contents/MacOS/XUL +0x0001061D] _ZL7do_mainiPPc+0x00000347 [/Users/jkew/mozdev/mozilla-central/./obj-ff-dbg/dist/NightlyDebug.app/Contents/MacOS/firefox +0x00001524] main+0x0000023B [/Users/jkew/mozdev/mozilla-central/./obj-ff-dbg/dist/NightlyDebug.app/Contents/MacOS/firefox +0x00001C9B] When this happens, we don't appear to detect it as a crash - I get the Apple crash-reporting dialog, not ours, and the next startup behaves normally. So it presumably won't be showing up on crash-stats, even if it's happening to other people.
In my debug build it usually takes around 0.05ms for the tracer thread to be notified (through the condition variable) that sTracerProcessed has been set to true in SignalTracerThread. When SignalTracerThread is called a second time during this window, sTracerProcessed hasn't been set to false yet, so we get the abort. What happens here is that SignalTracerThread is first called from the event loop, and then right after that again from ShutdownEventTracing.
Assignee: nobody → mstange
Status: NEW → ASSIGNED
Attachment #677332 - Flags: review?(ted)
Comment on attachment 677332 [details] [diff] [review] remove abort Review of attachment 677332 [details] [diff] [review]: ----------------------------------------------------------------- This is a little worrisome, because I was trying to protect against a deadlock here, but if you're hitting this regularly then things are already broken.
Attachment #677332 - Flags: review?(ted) → review+
(In reply to Ted Mielczarek [:ted.mielczarek] from comment #2) > but if you're hitting this regularly then things are already > broken. Well, I think the only broken case is the shutdown case. SignalTracerThread expects to only be called while it's waiting for the tracer event, but ShutdownEventTracing calls it regardless of state.
Hmm author wasn't set, so backed out and fixed: https://hg.mozilla.org/integration/mozilla-inbound/rev/d94bbc67a784 https://hg.mozilla.org/integration/mozilla-inbound/rev/83046064e7fe Please can you set the author in your hgrc :-)
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla20
You need to log in before you can comment on or make changes to this bug.