Closed Bug 688062 Opened 10 years ago Closed 10 years ago

[Mac] Not getting Breakpad when Mac crashes


(Toolkit :: Crash Reporting, defect)

Not set



Tracking Status
firefox8 --- unaffected
firefox9 + ---


(Reporter: marcia, Assigned: glandium)




(Keywords: regression)


(2 files)

Attached image Screenshot of issue
Today I noticed that the Mac crash rate seemed a bit low today. I looked this morning and there were only 18 or so crashes for the day, and when I looked again the number was the same.

Today I tried to reproduce a crash and got the attached dialog. I am using the site in the URL with the "Road to Ribbon" demo to reproduce the crash. When I crash on Aurora I get the crash reporter dialog.

We are taking a look at the data to see how long this might have been happening.
According to crash data and Marcia's tests, the regression range of Breakpad not being triggered is (last Mac crashes have been coming in from the 15th Build ID, Marcia got Breakpad with the 15th build but not the 16th build). This contains mostly build system stuff, but nothing sticks out for me. Ted, Kyle, what could be going on?
Summary: [Mac] Breakpad not submitting Mac crashes? → [Mac] Not getting Breakpad when Mac crashes
Forgot to add I am seeing this on trunk only.
Version: unspecified → Trunk
Don't think so - in the Windows case we are actually getting reports, it is just the signature that is wrong. In the Mac case there is no way to submit the report since the dialog never comes up.

(In reply to Jim Jeffery not reading bug-mail 1/2/11 from comment #3)
> dupe of >?
I bet this has the same root cause as the updater bustage, but I'm too tired to find that bug.
You're thinking about bug 687139. That's plausible. What is the path of the crash reporter ?
Looks like it's in a subdirectory as well. I'll check the whole contents of a dmg later today to see if there aren't more of those surprises.
It looks like this is the last bit that is linked against libmozutils and that is not in the same directory as the libraries. Actually, there is also plugin-container, but that is very well intended. It is linked against all the other libs anyways and we do set DYLD_LIBRARY_PATH so that it works.

Do we have crash reporter tests at all? If we do, then we don't test under the real conditions, obviously (like for the updater)
Attachment #561423 - Flags: review?(ted.mielczarek)
Comment on attachment 561423 [details] [diff] [review]
Avoid linking the crash reporter against libmozutils

Review of attachment 561423 [details] [diff] [review]:

We do not have tests that actually invoke the crashreporter client, because it's a pain to test native GUIs, and I never implemented an "automatically submit and close" function to make it easier to test. Sorry. :-(

::: toolkit/crashreporter/client/
@@ +54,5 @@
>  ifneq ($(OS_TARGET),Android)
>  PROGRAM = crashreporter$(BIN_SUFFIX)
>  DIST_PROGRAM = crashreporter$(BIN_SUFFIX)
> +
> +# Don't link the updater against libmozutils. See bug 688062

bug number is kind of overkill, since you can get it from blame.
Attachment #561423 - Flags: review?(ted.mielczarek) → review+
Assignee: nobody → mh+mozilla
Closed: 10 years ago
Resolution: --- → FIXED
Whiteboard: [inbound]
Target Milestone: --- → mozilla9
Verified fixed using  Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0a1) Gecko/20110923 Firefox/9.0a1. I now get the crash reporter when I visit the site in Comment 0.
You need to log in before you can comment on or make changes to this bug.