Open Bug 382541 Opened 13 years ago Updated 9 years ago
No way to stop Mozilla Crash Reporter from suppressing writing of Mac OS X crash log
STR: 1. https://bugzilla.mozilla.org/attachment.cgi?id=258932 2. Crash 3. Check console.log or ~/Library/Logs/CrashReporter/firefox-bin.log Expected: 1. Entry in console.log similar to: May 31 00:13:33 Krak-des-Chevaliers crashdump: Finished writing crash report to: /Users/smokey/Library/Logs/CrashReporter/Camino.crash.log 2. New crash in firefox-bin.crash.log Actual: 1. Absence of an entry in console.log about writing crash report 2. Latest crash in firefox-bin.crash.log is from April luser mentioned we were going to suppress the OS "this app has crashed" dialogue, and that's OK, but I have serious reservations about suppressing the *writing* of the crash to the log. 1. I know of no other 3rd-party Mac crash reporter that suppresses writing the log completely; the ones I'm familiar with either "borrow" the crash report from the normal log, or they intervene but still write the OS log to another location. Plus, and maybe I'm just odd, I consider the crash log to be my own personal data, and I object to someone stealing it from me completely. 2. Until breakpad can report loaded library versions, there's absolutely dataloss. There may or may not be other stuff in the OS log that might be interesting/useful, but that's the one thing I know of for sure. 3. If there are problems at any point along the way to the server, etc., or if the report "ages out", that crash data is irrevocably lost; with the real Mac OS X log, you can still provide useful data on the crash later on. 4. If a developer wants to see a crash log in his/her own build, he/she needs to build with --disable-airbag, which seems like a pain and/or a "gotcha". 5. When I crash, whether in my own build or in an official build, I don't want to wait for the report to make it to the server and be processed to see where I crashed. If the crash is reproducible for me, I want to search for an existing bug right away or file a new bug if there's no existing one. If I have to wait, I often will have to wait until my next "Mozilla time" and may forget about it.
(I was on my way to file this...) This is quite annoying for testers - I have turned ON advanced preferences for Apple's crash reporter (using /Developer/Applications/Utilities/CrashReporterPrefs.app) which provides me instant feed back in case of a crash: an expanded OS "this app has crashed" dialogue, with the first few lines of the crash log.
mento: can we allow writing of the crash log, and suppress the dialog?
How about suppressing the OS crash dialog if it's set to Basic mode, but not suppressing it if it's set to Developer mode?
I'm thinking for a short-term solution we can add a setting that will cause us to pass the exception up to the OS, so you'll get the OS X Crash Reporter dialog in addition to our Crash Reporter dialog. In the longer-term, we might want to use the code in Breakpad's tools/mac/crash_report to generate a OS X-style crash report on the client, and display it from our client.
Assignee: nobody → ted.mielczarek
This is intended as a short-term workaround. It allows you to do: defaults write org.mozilla.firefox OSCrashReporter 1 and have the OS Crash Reporter dialog show up (along with our crash reporter dialog). You get a messy stack of dialogs, but it will let you see the immediate stack as well as submit a report to Mozilla.
Attachment #266792 - Flags: review?(mark)
Comment on attachment 266792 [details] [diff] [review] short term workaround [checked in] > Index: toolkit/airbag/mac_utils.mm #include the header in this file, just for fun. Looks good.
Attachment #266792 - Flags: review?(mark) → review+
Comment on attachment 266792 [details] [diff] [review] short term workaround [checked in] Checked in, I'm leaving this open for a better solution.
Attachment #266792 - Attachment description: short term workaround → short term workaround [checked in]
I set the pref, and only some crash reports are making it through to firefox-bin.crash.log :(
I think I've found the bug (or at least a bug): You get different results depending on which of the following you use to set OSCrashReporter: defaults write org.mozilla.firefox OSCrashReporter 1 defaults write org.mozilla.firefox OSCrashReporter true In my experience the first one always works, but the second one never works. (When you set OSCrashReporter to '1', osCrashReporter is always set to '1' in mac_utils.mm's PassToOSCrashReporter(), and PassToOSCrashReporter() always returns '1'. But if you set OSCrashReporter to 'true', osCrashReporter is always set to '0' and PassToOSCrashReporter() always returns '0'.) When PassToOSCrashReporter() returns '1', I always see a crashreporterd window after I've dismissed the Breakpad window ... though it usually takes 10-15 seconds to show up.
Oh, yuck, right. defaults detects "true" as a string. Try: defaults write org.mozilla.firefox OSCrashReporter -bool true Sorry for misleading you earlier.
> defaults write org.mozilla.firefox OSCrashReporter -bool true This works. But if you're going to expect users to run the defaults command, it might be best to recognize string values for this setting (though I admit it'll be a pain to explicitly look for "true", "yes", "on" and so forth). > When PassToOSCrashReporter() returns '1', I always see a > crashreporterd window after I've dismissed the Breakpad window > ... though it usually takes 10-15 seconds to show up. I've started to see some variation here: Breakpad often starts minimized (or quickly gets put behind other windows?), and when this happens the crashreporterd window will come up right away. Most interestingly, the crashreporterd window fails to come up at all when the browser starts with a double-bounce (and only on the double-bounce, as far as I can tell) -- even though PassToOSCrashReporter() returns '1' on both bounces.
Bug 382540 is filed on the MozCrashReporter opening in the background.
(In reply to comment #11) > This works. But if you're going to expect users to run the defaults > command, it might be best to recognize string values for this setting > (though I admit it'll be a pain to explicitly look for "true", "yes", > "on" and so forth). We don't expect users to do this, it's a developer feature. > Most interestingly, the crashreporterd window fails to come up at all > when the browser starts with a double-bounce (and only on the > double-bounce, as far as I can tell) -- even though > PassToOSCrashReporter() returns '1' on both bounces. By double-bounce, do you mean the XRE restart? This may have something to do with the parent process having its own Breakpad handler installed. It may help to tear down the Breakpad handler before doing an XRE restart, or to postpone Breakpad handler installation until after we're sure we won't restart (but then we'd miss early crashes, so that's bad).
> By double-bounce, do you mean the XRE restart? Yes.
I don't have a better solution, and nobody has really complained lately, so I'm closing this out. Feel free to file a new bug if you come up with a better idea.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Summary: Mozilla Crash Reporter suppresses writing of Mac OS X crash log → No way to stop Mozilla Crash Reporter from suppressing writing of Mac OS X crash log
I'm still not seeing the OS crash reporter on 10.4.10 using Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a8pre) Gecko/2007082304 Minefield/3.0a8pre. I'm 99.9% sure I enabled the pref right. h-195% defaults read org.mozilla.firefox OSCrashReporter 1
Colin's right; this isn't working "anymore". I have a Minefield 3.0a7pre from 14 July here, and it doesn't work in that build. I know the defaults twiddling did work right after it was checked in (at least on 10.3 ;)) since I tested to check ;), but I don't know when it might have broken; I don't keep a stable stocked with Minefields. Another one of those magic regressions :(
Sam suggest reopening this bug ;)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
http://bonsai.mozilla.org/cvslog.cgi?file=/mozilla/toolkit/crashreporter/nsExceptionHandler.cpp&rev=HEAD&mark=1.23 1.16 was when this was checked in, and 1.23 is current as of today. FWIW.
What am I missing? Bugzilla says the patch was checked in on 2 June, but Colin's bonsai link says it wasn't checked in until 24 July!?
All revisions except the newest one are the same time/date. Probably just CVS sucking.
When you cvs copy a file all revisions gets a new date (copying date).
FWIW, this totally still works for me. defaults read org.mozilla.firefox OSCrashReporter 1 Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a8pre) Gecko/2007091304 Minefield/3.0a8pre And I get the OSX Crash Reporter.
The other day I was looking at something in the same build as comment 17 and had an unexpected crash, and that time the anti-suppression mechanism worked, too, but the crash I had been using to test this (and other trunk crashes of that era) wouldn't trigger the Mac OS X reporter at all (when it had previously). Maybe there's some set of conditions that cause it not to work?
Not sure, I just tested with the attachment on bug 378521.
[09/20-10:26][pikun:~] $ defaults read org.mozilla.firefox OSCrashReporter 1 With official builds, I never get the OS X crash report, but BreakPad works (at least it did last time I was testing crashes, 3 days ago). With home-made builds (debug or opt) it works. OS 10.4.10, PPC - maybe that matters ?
That seems consistent with what I see as well? I think?
(From comment #11) > Most interestingly, the crashreporterd window fails to come up at > all when the browser starts with a double-bounce (and only on the > double-bounce, as far as I can tell) -- even though > PassToOSCrashReporter() returns '1' on both bounces. Is this still true? Could this be the pattern people are trying to find?
Assignee: ted.mielczarek → nobody
Status: REOPENED → NEW
I spent a couple of hours crashing ted's test build from bug 404855 on 10.5.1/Intel, and this was definitely working fine for me. B2 also seems to honor the non-suppress user default. Not sure how to trigger an XRE restart to check for that, though.
You need to log in before you can comment on or make changes to this bug.