Closed Bug 1164052 Opened 9 years ago Closed 4 years ago

intermittent autophone-s1s2 | application crashed [unknown top frame]

Categories

(Firefox for Android Graveyard :: General, defect, P5)

ARM
Android
defect

Tracking

(firefox41 affected, fennec+)

RESOLVED INCOMPLETE
Tracking Status
firefox41 --- affected
fennec + ---

People

(Reporter: bc, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: crash, intermittent-failure)

Attachments

(1 file)

(deleted), application/vnd.tcpdump.pcap
Details
Attached file minidump (deleted) —
Autophone will occasionally fail to obtain measurements due to a crash however minidump_stackwalk will fail to parse the dmp file. Example: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=3cd634573d29&exclusion_profile=false&filter-searchStr=autophone https://autophone.s3.amazonaws.com/pub/mozilla.org/mobile/tinderbox-builds/mozilla-inbound-android-api-11/1431321451/autophone-s1s2-s1s2-blank-remote.ini-1-nexus-4-jdq39-2-logcat.log https://autophone.s3.amazonaws.com/pub/mozilla.org/mobile/tinderbox-builds/mozilla-inbound-android-api-11/1431321451/autophone-autophone-s1s2-s1s2-blank-remote.ini-1-nexus-4-jdq39-2.log mindump_stackwalk fails with messages like: Minidump header signature mismatch: (0x0, 0x0) != 0x504d444d I've recently updated the version of minidump_stackwalk Path: . URL: http://google-breakpad.googlecode.com/svn/trunk Repository Root: http://google-breakpad.googlecode.com/svn Repository UUID: 4c0a9323-5329-0410-9bdc-e9ce6186880e Revision: 1454 Node Kind: directory Schedule: normal Last Changed Author: primiano@chromium.org Last Changed Rev: 1454 Last Changed Date: 2015-04-30 02:12:54 -0700 (Thu, 30 Apr 2015) This bug is meant to track the crash as well as hopefully diagnose and fix the failure to parse the minidump.
ted: Any idea what might be up with this minidump? Am I building minidump from the proper repo now?
Flags: needinfo?(ted)
(In reply to Bob Clary [:bc:] from comment #0) > Minidump header signature mismatch: (0x0, 0x0) != 0x504d444d This means the minidump isn't being written properly. It's trying to read the 4-byte header and getting zeroes instead of the expected value. This sounds very similar to bug 1045804, Geoff was looking into that for a long time but I don't know that he ever actually got anywhere.
Flags: needinfo?(ted)
I did not get very far. https://bugzilla.mozilla.org/show_bug.cgi?id=1045804#c15 was the most interesting thing I found and might be the place to pick up the hunt. I was seeing this issue on Pandaboards, especially in the case of robocop hangs; I gave up since it hadn't recurred lately and Panda use is on the decline.
This is pretty frequent on Autophone. Geoff, which would you recommend: forcing signalHandlingSlow = 1 or updating the in tree breakpad ? Updating the in tree version of breakpad seems like a good thing. The are actively maintaining it and picking up fixes seems like a good thing.
PS. I do see breakpad related crashes in Bughunter's crash automation that might also be helped by updating.
I would like to see an update to the in tree breakpad.
filed bug 1167305 about updating.
tracking-fennec: ? → 41+
Depends on: 1069556
Assignee: nobody → ted
Summary: Autophone - intermittent Crash [unknown top frame] → PROCESS-CRASH | autophone-s1s2 | application crashed [unknown top frame]
tracking-fennec: 41+ → +
Summary: PROCESS-CRASH | autophone-s1s2 | application crashed [unknown top frame] → intermittent PROCESS-CRASH | autophone-s1s2 | application crashed [unknown top frame]
bc: I landed a Breakpad update recently that made it into today's Nightly. I don't know if it will have an impact on this issue or not, but maybe you can look at logs and compare?
Flags: needinfo?(bob)
Yes, I hope to accumulate some crashes soon and see how the new breakpad does compared to the old. Thanks! I'll let you know.
Ted, do I need a minidump_stackwalker builds from tip of the tree or are builds from the last few months sufficient?
Flags: needinfo?(ted)
I don't think there have been any significant fixes to that side of things since the last time we talked about this. snorp has a patch in bug 1247978 that might fix some of these.
Flags: needinfo?(ted)
Ok, great. As is, I'm still seeing application crashed [None] though it does appear to have a dump as mentioned in that bug. Thanks! Looking forward to it. Thanks for all of your work on this. I know it seems like an unproductive thing to spend your time on, but I for one definitely appreciate it.
Flags: needinfo?(bob)
Flags: needinfo?(snorp)
We have some known issue with busted reports (bug 1245570), but don't have any actionable stuff yet.
Flags: needinfo?(snorp)
Bulk assigning P3 to all open intermittent bugs without a priority set in Firefox components per bug 1298978.
Priority: -- → P3
Summary: intermittent PROCESS-CRASH | autophone-s1s2 | application crashed [unknown top frame] → intermittent autophone-s1s2 | application crashed [unknown top frame]
Re-triaging per https://bugzilla.mozilla.org/show_bug.cgi?id=1473195 Needinfo :susheel if you think this bug should be re-triaged.
Priority: P3 → P5
Assignee: ted → nobody
We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → INCOMPLETE
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: