Closed Bug 983211 Opened 6 years ago Closed 5 years ago
crash in @0x40098bd4 corrupt crash stack on x86 tablets Galaxy Tab 3 10
This bug was filed from the Socorro interface and is report bp-bf7167db-e3ee-4bc5-8df4-bd85e2140313. ============================================================= The samsung GT-P5210 17 (REL) samsung GT-P5200 17 (REL)
Crashes interacting with the back button. Don't see this signature on Beta 8.
Bisecting on beta as there are fewer items in the regression range. http://hg.mozilla.org/releases/mozilla-beta/pushloghtml?fromchange=FENNEC_28_0b8_RELEASE&tochange=FENNEC_28_0b10_RELEASE
Pretty sure the crash is happening inside media code, > mozilla::MediaPluginHost::DestroyDecoder(MPAPI::Decoder*) > mozilla::MediaPluginReader::ResetDecode > mozilla::MediaPluginReader::~MediaPluginReader
That makes Bug 970076 the likely suspect. Given that we are trading a more common crash for a less common one it makes sense to relnote this and work on a fix for 29.
I've added this to the FF28 release notes in Known Issues for now.
Made a build with 970076 backed out I am able to play the videos from http://people.mozilla.org/~cpeterson/videos/ without crashing.
Edwin - Any thoughts on this? What hardware do you need?
Assignee: nobody → edwin
tracking-fennec: ? → 28+
clear STR 1. Load http://people.mozilla.org/~cpeterson/videos/ 2. Load a mp4 video 3. Press back 4. Repeat steps 2 and 3 till crash Normally about 3 videos.
(In reply to Kevin Brosnan [:kbrosnan] from comment #6) > Made a build with 970076 backed out I am able to play the videos from > http://people.mozilla.org/~cpeterson/videos/ without crashing. We're planning a mobile-only dot release for bug 963621 so if a backout of bug 970076 is low-risk and puts us back to a known-good state I'm open to uplift nomination to ride along. This is a non-urgent dot release, we can take the time to verify this on a nightly mozilla-release build before going to build on the 28.0.1 candidate.
See comment 4 backout puts us in a worse crash spot. We are trading a top crash on "Android 4.2 and 4.3 devices with Qualcomm SoCs" for for a top crash on the Samsung Galaxy Note 3 10 inch tablets.
6 years ago
Oops. Keep ni? to remind myself to come back around to this.
Edwin, we are going to build 29 beta 3 today. It would be nice if a patch could land soon to have time.
Ordered RITM0025312 for testing.
Just received the device and couldn't reproduce. Nightly 2014-04-01 crashes; nightly 2014-04-04 doesn't. It looks like bug 812881 may have fixed it. kbrosnan, can you confirm and resolve as dupe?
Flags: needinfo?(edwin) → needinfo?(kbrosnan)
Looks like it from some internal testing on the Galaxy Tab 3 10.1. I am going to wait on b8 data which should be good on the 16th or so to resolve.
(In reply to Kevin Brosnan [:kbrosnan] from comment #15) > Looks like it from some internal testing on the Galaxy Tab 3 10.1. I am > going to wait on b8 data which should be good on the 16th or so to resolve. From all I see, it's actually gone in b8 data as well! \o/ Should we mark this a dupe of bug 812881 or just mark it fixed and set a dependency?
Going to go with fixed.
Verified as fixed in builds: 29.0 30.0 31.0a2 (2014-06-09) 32.0a1 (2014-06-09) Device: Asus Transformer Pad TF300T (Android 4.2.1)
(In reply to cristina.madaras from comment #18) > Device: > Asus Transformer Pad TF300T (Android 4.2.1) Hmm, how can you verify a x86-only crash with an ARM tablet? That said, I think the reduced x86 crash volume starting with 29 is enough for verification here, but I still wonder about your way of verification here.
(In reply to Robert Kaiser (:firstname.lastname@example.org) from comment #19) > (In reply to cristina.madaras from comment #18) > > Device: > > Asus Transformer Pad TF300T (Android 4.2.1) > > Hmm, how can you verify a x86-only crash with an ARM tablet? > > That said, I think the reduced x86 crash volume starting with 29 is enough > for verification here, but I still wonder about your way of verification > here. Sorry! my mistake, I didn't see it's an x86 issue. Based on your last comment can we consider this verified fixed?
I think based on data we can call it verified fixed (though it wouldn't harm to try on the x86 tablet with the STR that Kevin used). There are still crashes with signatures of that kind, but they are significantly lower volume than before 29, so the remaining ones might be a different issue in the end. Kevin, since you did reproduce in comment #2 and obviously had access to such a tablet, can you try again to confirm verification here?
I did that in comment 15
(In reply to Kevin Brosnan [:kbrosnan] from comment #22) > I did that in comment 15 Oops, OK, then let's call it verified. :)
You need to log in before you can comment on or make changes to this bug.