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

Categories

(Core :: Widget, defect)

x86_64
macOS
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla20

People

(Reporter: jfkthame, Assigned: mstange)

References

Details

Attachments

(1 file)

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.
Attached patch remove abortSplinter Review
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.
Blocks: 822354
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 :-)
https://hg.mozilla.org/mozilla-central/rev/83046064e7fe
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.