Closed Bug 427210 Opened 16 years ago Closed 15 years ago

Crash reporter fails to send useful dumps from an AMD64 system even from an official 32-bit Linux build

Categories

(Toolkit :: Crash Reporting, defect)

Product:
Toolkit
Component:
Crash Reporting
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: wgianopoulos, Unassigned)

References

Details

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
Flags: blocking1.9?
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.
Summary: Crash reporter fails to send useful dumps from an x86_64 system even from an official 32-bit Linux build → Crash reporter fails to send useful dumps from an AMD64 system even from an official 32-bit Linux build
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.
Flags: blocking1.9? → blocking1.9-
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".
Hardware: x86 → 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.)
Depends on: 514188
This is likely to be fixed now.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
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
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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
Status: REOPENED → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
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.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
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
Status: REOPENED → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
Thanks for testing!
You need to log in before you can comment on or make changes to this bug.