688062 - [Mac] Not getting Breakpad when Mac crashes

Status: VERIFIED FIXED

(Toolkit :: Crash Reporting, defect)

Description

[Marcia Knous [:marcia]]

Attachment: 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.

Comment 1

[Robert Kaiser]

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?

Comment 2

[Marcia Knous [:marcia]]

Forgot to add I am seeing this on trunk only.

Comment 3

[Jim Jeffery not reading bug-mail 1/2/11]

dupe of https://bugzilla.mozilla.org/show_bug.cgi?id=687888 >?

Comment 4

[Marcia Knous [:marcia]]

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 >?

Comment 5

[(not currently active) Ted Mielczarek]

I bet this has the same root cause as the updater bustage, but I'm too tired to find that bug.

Comment 6

[Mike Hommey [:glandium]]

You're thinking about bug 687139. That's plausible. What is the path of the crash reporter ?

Comment 7

[Mike Hommey [:glandium]]

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.

Comment 8

[Mike Hommey [:glandium]]

Attachment: Avoid linking the crash reporter against libmozutils

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)

Comment 9

[(not currently active) 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.

Comment 10

[Mike Hommey [:glandium]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/2089dc93c432

Comment 11

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/2089dc93c432

Comment 12

[Marcia Knous [:marcia]]

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.