[Mac] Not getting Breakpad when Mac crashes

VERIFIED FIXED in mozilla9

Status

()

defect
--
blocker
VERIFIED FIXED
8 years ago
8 years ago

People

(Reporter: marcia, Assigned: glandium)

Tracking

({regression})

Trunk
mozilla9
x86
macOS
Points:
---

Firefox Tracking Flags

(firefox8 unaffected, firefox9+)

Details

()

Attachments

(2 attachments)

Posted 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 http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2011-09-15+00%3A00%3A00&enddate=2011-09-16+04%3A00%3A00 (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 https://bugzilla.mozilla.org/show_bug.cgi?id=687888 >?
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/Makefile.in
@@ +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
https://hg.mozilla.org/mozilla-central/rev/2089dc93c432
Status: NEW → RESOLVED
Closed: 8 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.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.