Open
Bug 382541
Opened 17 years ago
Updated 5 months ago
No way to stop Mozilla Crash Reporter from suppressing writing of Mac OS X crash log
Categories
(Toolkit :: Crash Reporting, defect)
Tracking
()
NEW
People
(Reporter: alqahira, Unassigned)
Details
(Whiteboard: [notacrash])
Attachments
(1 file)
8.39 KB,
patch
|
mark
:
review+
|
Details | Diff | Splinter Review |
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.
Comment 1•17 years ago
|
||
(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.
Comment 2•17 years ago
|
||
mento: can we allow writing of the crash log, and suppress the dialog?
Comment 3•17 years ago
|
||
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?
Comment 4•17 years ago
|
||
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
Comment 5•17 years ago
|
||
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 6•17 years ago
|
||
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 7•17 years ago
|
||
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]
Comment 8•17 years ago
|
||
I set the pref, and only some crash reports are making it through to firefox-bin.crash.log :(
Comment 9•17 years ago
|
||
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.
Comment 10•17 years ago
|
||
Oh, yuck, right. defaults detects "true" as a string. Try: defaults write org.mozilla.firefox OSCrashReporter -bool true Sorry for misleading you earlier.
Comment 11•17 years ago
|
||
> 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.
Reporter | ||
Comment 12•17 years ago
|
||
Bug 382540 is filed on the MozCrashReporter opening in the background.
Comment 13•17 years ago
|
||
(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).
Comment 14•17 years ago
|
||
> By double-bounce, do you mean the XRE restart?
Yes.
Comment 15•17 years ago
|
||
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: 17 years ago
Resolution: --- → FIXED
Updated•17 years ago
|
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
Comment 16•17 years ago
|
||
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
Reporter | ||
Comment 17•17 years ago
|
||
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 :(
Reporter | ||
Comment 18•17 years ago
|
||
Sam suggest reopening this bug ;)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 19•17 years ago
|
||
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.
Reporter | ||
Comment 20•17 years ago
|
||
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!?
Comment 21•17 years ago
|
||
All revisions except the newest one are the same time/date. Probably just CVS sucking.
Comment 22•17 years ago
|
||
When you cvs copy a file all revisions gets a new date (copying date).
Comment 23•17 years ago
|
||
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.
Reporter | ||
Comment 24•17 years ago
|
||
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?
Comment 25•17 years ago
|
||
Not sure, I just tested with the attachment on bug 378521.
Comment 26•17 years ago
|
||
[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 ?
Comment 27•17 years ago
|
||
That seems consistent with what I see as well? I think?
Comment 28•17 years ago
|
||
(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?
Updated•17 years ago
|
Assignee: ted.mielczarek → nobody
Status: REOPENED → NEW
Reporter | ||
Comment 29•16 years ago
|
||
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.
Updated•15 years ago
|
Whiteboard: [notacrash]
Comment 30•2 years ago
|
||
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: major → --
Comment 31•5 months ago
|
||
The severity field is not set for this bug.
:gsvelto, could you have a look please?
For more information, please visit BugBot documentation.
Flags: needinfo?(gsvelto)
Updated•5 months ago
|
Severity: -- → S3
Flags: needinfo?(gsvelto)
You need to log in
before you can comment on or make changes to this bug.
Description
•