I thought we should have a bug here to track the upstream issue reported here: http://code.google.com/p/google-breakpad/issues/detail?id=227

Here is a link to a crash report I submitted from the beta5 build. http://crash-stats.mozilla.com/report/index/cb3bb1d9-fd86-11dc-bf27-001a4bd43ef6

hm i cannot confirm this, on Fedora 8 x64 i get with beta 5 a useful stack like http://crash-stats.mozilla.com/report/index/2348a51c-030a-11dd-b0e4-001cc45a2c28

This must be AMD64 only then.

Too late in the game to block on this, especially if it works on some other systems. I thought we already had a bug in bugzilla on this, but I didn't check.

Hmm. rc2 build1 works fine for me on Gentoo x86_64 when I install libgconf libcurl and dependencies from an i686 Gentoo. (Those dependencies are required to upload anything at all.) The missing info in bp-cb3bb1d9-fd86-11dc-bf27-001a4bd43ef6 would seem to be related to the minidump. The RawDump is empty but extra parameters are present.

Right, breakpad failed to gather the needed info in the dump. Breakpad uses /proc/self/maps to gather info about loaded modules. I think the problem might have been that it was seeing 64 bit addresses in there, and expecting 32 bit addresses.

Interesting. So even 32-bit processes can have some 48-bit offsets in /proc/<pid>/maps (on x86_64): ffcd4000-ffce8000 rwxp 7ffffffea000 00:00 0 [stack] ffce8000-ffce9000 rw-p 7fffffffe000 00:00 0 Maybe crash reporting WFM because all the addresses are 32-bit.

I've been running 64-bit Firefox nightlies on Kubuntu 9.10 amd64 for months and breakpad/crash reporter has never appeared after one of my frequent crashes. Besides Google bug 227, might http://code.google.com/p/google-breakpad/issues/detail?id=299 also be relevant? Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a1pre) Gecko/20091201 Minefield/3.7a1pre ID:20091201031028

Can someone please change the hardware platform field of this bug to "x86_64".

bug 514188 will probably fix this. The Linux client code was rewritten. (It appears to work natively on x86-64 Linux as well, now.)

This is likely to be fixed now.

This is NOT fixed. See this dump. http://crash-stats.mozilla.com/report/index/bp-559023f2-4259-4b1c-9fb4-ee61f2091215 created under this build: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.3a1pre) Gecko/20091215 Minefield/3.7a1pre

HMm I must have screwed up on myh first test somehow. It is fixed. See this crash report: http://crash-stats.mozilla.com/report/index/bp-34b00759-81d2-4ada-bd80-2f1d92091215

Hmm obvisously from the reported buildid in the first crash it thinks I am not running what I thought I was running. The first test was from after starting buildid 20091214030830 and auto-updating to 20091215030948 and then forcing the crash. Note that the crashdump says I am still running 20091214030830. Either I screwed up or there is something odd with crashreporter and doing an auto-update restart. If this turns out to be reproducible and not just cockpit error I will file a new bug on that issue.

Re-opening since the bug 514188 code that fixed this was backed out. Further, the new upstream code added to fix the new issue in bug 514188 contains the following comment: //TODO: support dumping 32-bit binaries from a 64-bit dump_syms? This kind of makes me think AMD64 crashes of official Linux 32-bit builds will continue to be unusable even after the sync to breakpad revision 461.

No, that's purely a cross-compiling issue (building 32-bit binaries on a 64-bit system). Crashing a 32-bit build on a 64-bit system should work fine. I'm planning on re-landing those patches ASAP.

Great! I will try a retest with the next nightly after the reland and hopefully close and verify this for good.

Please test with today's nightly.

Tested using Crash me Now! extension using Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.3a1pre) Gecko/20100105 Minefield/3.7a1pre ID:20100105030950: Looks great. All crash information is present including stack trace with symbols. bp-fc493f39-488c-4626-944f-621b72100105

Thanks for testing!