Closed Bug 1164052 Opened 9 years ago Closed 3 years ago

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

Categories

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

Product:
Firefox for Android Graveyard
Component:
General
Platform:
ARM
Android
Type:
defect

Tracking

(firefox41 affected, fennec+)

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

People

(Reporter: bc, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: crash, intermittent-failure)

Attachments

(1 file)

minidump
108.98 KB, application/vnd.tcpdump.pcap
Details
Attached file minidump — 
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+ → +
Keywords: intermittent-failure
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: 3 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.