Closed Bug 730282 Opened 8 years ago Closed 8 years ago
Firefox Crash @ mozilla::Signal
Low volume Mac crash. https://crash-stats.mozilla.com/report/list?signature=mozilla::SignalTracerThread Comments mention: Clicked "restart now" in one of several addons I removed or disabled in the addon manager I restarted Firefox to apply a new Firefox upgrade. https://crash-stats.mozilla.com/report/index/60609c30-812f-44d6-88d1-728ab2120223 Frame Module Signature Source 0 XUL mozilla::SignalTracerThread 1 XUL -[GeckoNSApplication sendEvent:] widget/cocoa/nsAppShell.mm:193 2 XUL ProcessPendingGetURLAppleEvents toolkit/xre/MacApplicationDelegate.mm:151 3 XUL CommandLineServiceMac::SetupMacCommandLine toolkit/xre/nsCommandLineServiceMac.cpp:101 4 XUL XRE_main toolkit/xre/nsAppRunner.cpp:1625 5 firefox main browser/app/nsBrowserApp.cpp:189 6 firefox firefox@0x1573
It first appeared in 12.0a1/20120107. There is a Widget Gtk version on Linux.
Hardware: x86 → x86_64
Summary: Firefox Crash [@ mozilla::SignalTracerThread ] → Firefox Crash in GeckoNSApplication sendEvent @ mozilla::SignalTracerThread
Version: Trunk → 12 Branch
Recategorizing because these also happen on Linux.
Component: Widget: Cocoa → Widget
QA Contact: cocoa → general
Hardware: x86_64 → All
Summary: Firefox Crash in GeckoNSApplication sendEvent @ mozilla::SignalTracerThread → Firefox Crash @ mozilla::SignalTracerThread
The crash stacks on Linux are much more informative: 0 libxul.so mozilla::SignalTracerThread Mutex.h:106 1 libxul.so TracerCallback widget/gtk2/WidgetTraceEvent.cpp:58 2 libglib-2.0.so.0.3000.0 libglib-2.0.so.0.3000.0@0x44a5c 3 libglib-2.0.so.0.3000.0 libglib-2.0.so.0.3000.0@0x4078f 4 libxul.so mozilla::SignalTracerThread Mutex.h:188 5 @0x9 6 libxul.so nsAppShell::ScheduleNativeEventCallback widget/gtk2/nsAppShell.cpp:157 7 @0x7fe981c4e01f 8 libglib-2.0.so.0.3000.0 libglib-2.0.so.0.3000.0@0x45257 9 libglib-2.0.so.0.3000.0 libglib-2.0.so.0.3000.0@0x2f4827 10 libglib-2.0.so.0.3000.0 libglib-2.0.so.0.3000.0@0x2f483f 11 libpthread-2.13.so libpthread-2.13.so@0x9fff 12 libglib-2.0.so.0.3000.0 libglib-2.0.so.0.3000.0@0x45428 13 libxul.so nsAppShell::ProcessNextNativeEvent widget/gtk2/nsAppShell.cpp:162 ...
> It first appeared in 12.0a1/20120107. bp-2027c29e-c6e5-494d-ab45-8554f2120128 On Linux the first one is in build 20120105083933: bp-76c558bf-ebac-4799-a0a1-584582120105
(Following up comment #4) I can't find any obvious candidate for this bug's trigger among the patches landed just before the 2012-01-05 nightlies. In any case this crash is too low volume to use build ids to identify the exact build they started in.
On Linux these crashes appear to take place at the following line, probably after a call to mozilla::CleanUpWidgetTracing() had invalidated sMutex: http://hg.mozilla.org/releases/mozilla-aurora/annotate/cd3f31d128b8/widget/gtk2/WidgetTraceEvent.cpp#l102
On OS X I'd bet they take place at the following line, for the same reason: http://hg.mozilla.org/mozilla-central/annotate/58dd942011a8/widget/cocoa/WidgetTraceEvent.mm#l77
On Windows we *should* be seeing crashes at the following line: http://hg.mozilla.org/mozilla-central/annotate/58dd942011a8/widget/windows/WidgetTraceEvent.cpp#l134 I'm not sure why we don't.
Benoit added some APIs to let us enable this tracing functionality in a scriptable manner, for use with the profiling extension. This functionality is off by default (and only normally enabled via environment variable), so it's unlikely to affect users that haven't installed the profiling extension. Steven: the widget-specific bits are fairly different, so it wouldn't surprise me if Windows doesn't crash here. In fact, we have a known Linux shutdown crash in this code (bug 710296), which is why we didn't enable it on Linux Talos yet.
I looked through the crash reports, the only extensions that I know are using this are 'about:jank' and 'Gecko Profiler', none of which show up in the crash report. Could they show up under <id>@jetpack?
These crashes should be very easy to fix: Just make CleanUpWidgetTracing() null out sMutex (on OS X and Linux). And for good measure, on Windows CleanUpWidgetTracing() should null out sEventHandle. I don't know if widget tracing has been implemented on other platforms. But if it has, similar changes would be needed there.
(Following up comment #11) Oops, the code already does this on OS X and Linux. I meant to say that, on these platforms, SignalTracerThread() should check if sMutex or sCondVar is NULL. Patch coming up.
Assignee: nobody → smichaud
Attachment #603449 - Flags: review?(ted.mielczarek)
Comment on attachment 603449 [details] [diff] [review] Fix Review of attachment 603449 [details] [diff] [review]: ----------------------------------------------------------------- Seems plausible. It's definitely going to crash if either of those are NULL. You'll want to watch the Talos Tp5 runs on Tinderbox, because we run Windows/Mac with this tracing enabled there.
Attachment #603449 - Flags: review?(ted.mielczarek) → review+
Comment on attachment 603449 [details] [diff] [review] Fix Landed on mozilla-inbound: http://hg.mozilla.org/integration/mozilla-inbound/rev/1c7831aa244d
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla13
You need to log in before you can comment on or make changes to this bug.