Closed Bug 927433 Opened 7 years ago Closed 7 years ago
[Music] Music App crashes each time it is opened
Buri device, using: Gaia 3d4f1107e6e91e5f5649edc0f2565ac837111d7d SourceStamp 9f63bbc00527 BuildID 20131016040202 Version 27.0a1 STR: 1. Open Music app 2. Crash https://crash-stats.mozilla.com/report/index/0ae8526f-1197-4909-a96f-d6a382131016 I have a second Buri device flashed with the same build and it doesn't happen with that device, but each device has different music files on them. Using yesterday's build with the identical songs I was not getting crashes when launching the Music app. Bug 914823 was opened for a similar stack, but I didn't want to muddy that bug with this crash since it is fixed and this might be a different issue. And I am also getting crashes with a slightly different signature: https://crash-stats.mozilla.com/report/index/66ab52d2-82c3-4862-b8e4-d52ee2131016
We have a number of similar bug reports about crashes in the Music app. These might be related to MP3 support. Could you find out which MP3 file causes the Music app to crash and make it available somehow?
(In reply to Thomas Zimmermann [:tzimmermann] [:tdz] from comment #1) > We have a number of similar bug reports about crashes in the Music app. > These might be related to MP3 support. Could you find out which MP3 file > causes the Music app to crash and make it available somehow? Sure, trying to look at the files I have now.
Let's keep this bug focused on the second crash stack, not the first. The first crash stack is likely because bug 914823 isn't exactly fixed, as the later comments imply.
Component: Gaia::Music → Video/Audio
Product: Boot2Gecko → Core
Version: unspecified → 27 Branch
I removed a bunch of MP3 files that I thought might be problematic, and so far I haven't been able to isolate it down to one file causing the crash.
Crash Signature: [@ mozilla::gl::SharedSurface_Gralloc::~SharedSurface_Gralloc] [@ android::OmxDecoder::Init(android::sp<android::MediaExtractor>&)] → [@ android::OmxDecoder::Init(android::sp<android::MediaExtractor>&)]
Adding a logcat. I will try some of Naoki's suggestions including swapping out the SD card to another phone to see if I can replicate the crash there.
The crash still occurs when I swap the SD card out to another phone, so I will have to continue drilling down through the tracks to see which one is the offending mp3.
Turns out that it happens only with one song as well. I backedup my sdcard and placed one song in: adb pull sdcard/ sdcard adb shell rm -r /sdcard adb push <song> /sdcard/<song> and removed the databases adb shell rm -r /data/local/storage/persistent/* rebooted the device: adb reboot and launched the music app and it still crashes: https://crash-stats.mozilla.com/report/index/b03a4e96-321d-4e58-adae-2dde82131017
I found out after digging into it more, it's not a file that can be seen by doing a regular ls -l when you delete a file on the mac, it leaves a ._<filename> and that's what's causing the issue. The attached file causes a crash.
Thanks to Naoki Hirata, I was able to reproduce this issue with his attached file. Regression Window: This issue reproduces on the 10/16 Buri v 1.3.0 Mozilla RIL Environmental Variables Device: Buri v 1.3.0 Mozilla RIL Build ID: 20131016040202 Gecko: http://hg.mozilla.org/mozilla-central/rev/9f63bbc00527 Gaia: 3d4f1107e6e91e5f5649edc0f2565ac837111d7d Platform Version: 27.0a1 The music app crashes when opened when it tries to load the file on the SD from comment 8. 100% Repro Rate. Crash Signature: android::OmxDecoder::Init(android::sp<android::MediaExtractor>&) The issue does not reproduce on the 10/15 Buri v 1.3.0 Mozilla RIL Environmental Variables Device: Buri v 1.3.0 Mozilla RIL Build ID: 20131015040202 Gecko: http://hg.mozilla.org/mozilla-central/rev/febfe3c7732b Gaia: 17e871ae1f82699793e3cd28acda805ba724a8b6 Platform Version: 27.0a1 The Music app launches without a crash occurring.
(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #8) > Created attachment 818738 [details] > music_bug.xz > > I found out after digging into it more, it's not a file that can be seen by > doing a regular ls -l > when you delete a file on the mac, it leaves a ._<filename> and that's > what's causing the issue. > > The attached file causes a crash. Hah! That's very interesting. I could not reproduce this crash so far, but was wondering if I needed a specific file on my sdcard. I'm at the gfx work week at the moment, which has kept me away from bugfixing, but will try this asap.
Still can't reproduce any crash on hamachi / v1.2. Which is actually also what comment 9 says (regression on central after the 1.2 branching). But I was interested in reproducing the SharedSurface_Gralloc signature (bug 914823) which is a 1.2 bug, and still can't reproduce :-/
Would it help if we send you the card where we can reliably reproduce this?
From the signature, it is a dup of Bug 932076.
Given that bug 932076 has the patch in place, I'm duping there.
Status: NEW → RESOLVED
blocking-b2g: 1.3? → ---
Closed: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 932076
You need to log in before you can comment on or make changes to this bug.