Closed Bug 1164052 Opened 6 years ago Closed 9 months ago
intermittent autophone-s1s2 | application crashed [unknown top frame]
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: firstname.lastname@example.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?
(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.
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
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?
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?
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.
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.
We have some known issue with busted reports (bug 1245570), but don't have any actionable stuff yet.
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
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: 9 months 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.