927242 - Crash while parsing mp3 files

Status: RESOLVED DUPLICATE of bug 924678

(Firefox OS Graveyard :: General, defect, P1)

Description

[bhargavg1]

Attachment: 00f29ae3-b46b-6ea4-2cbc0b8e-3e3dbe51.txt

Observed crash while starting the music app with the following clip

https://docs.google.com/file/d/0B0zTAnPOpx-xR0J0N1d3dDNmV0E/edit?usp=sharing

the crash wont happen always would happen only when enumerating the DB for the first time.

Observed the crash around the following build,

Gaia:  9e21b6bea92fdafcb6787120a8cde0eb25a50495
Gecko: 2476b6aaae1047642646ba5c442b2aa9fd18bf8f

Comment 1

[bhargavg1]

the issue can be easily reproduced if the above mentioned clip is the only one to enumerate

Comment 2

[Sotaro Ikeda [:sotaro]]

I is a bug of series of mp3 regression like Bug 923451, Bug 926125, Bug 924678, Bug 914870, Bug 922334, Bug 922953.

Comment 3

[Sotaro Ikeda [:sotaro]]

The crash might be related to Bug 924678. But it is not clear.

Comment 4

[Thomas Zimmermann [:tzimmermann] [:tdz]]

The stack trace looks like a duplicate of bug 924678.

Comment 5

[Thomas Zimmermann [:tzimmermann] [:tdz]]

I cannot access the file on Google docs. Can you send it to me by mail?

Comment 6

[bhargavg1]

(In reply to Thomas Zimmermann [:tzimmermann] [:tdz] from comment #5)
> I cannot access the file on Google docs. Can you send it to me by mail?

Sent the invite, you should be able to now

Comment 7

[Thomas Zimmermann [:tzimmermann] [:tdz]]

I cannot reproduce this bug on the Unagi.

Gaia: bc2fb252092af20050551ecbd7c5a3edab77b58e
Gecko: m-c 423b9c30c73d

Comment 8

[bhargavg1]

(In reply to Thomas Zimmermann [:tzimmermann] [:tdz] from comment #7)
> I cannot reproduce this bug on the Unagi.
> 
> Gaia: bc2fb252092af20050551ecbd7c5a3edab77b58e
> Gecko: m-c 423b9c30c73d

It is easily reproducible if the file is the only one to be enumerated after erasing the internal DB.

Comment 9

[bhargavg1]

(In reply to Thomas Zimmermann [:tzimmermann] [:tdz] from comment #7)
> I cannot reproduce this bug on the Unagi.
> 
> Gaia: bc2fb252092af20050551ecbd7c5a3edab77b58e
> Gecko: m-c 423b9c30c73d

Checked this on latest version easily reproduced,
Gecko: 5ef3535021286ccab7af639897feaaf5955720a0
Gaia: 1b2f9fa87dbb4c9bfbf009539cf813fa2841472b

Comment 10

[bhargavg1]

Attachment: mp3_issue.log

adb log attached

Comment 11

[cajbir (:cajbir)]

How can I get access to the file that causes the issue?

Comment 12

[bhargavg1]

(In reply to Chris Double (:doublec) from comment #11)
> How can I get access to the file that causes the issue?

You should be able to access now, sent and invite

Comment 13

[cajbir (:cajbir)]

(In reply to bhargavg1 from comment #12)
> (In reply to Chris Double (:doublec) from comment #11)
> > How can I get access to the file that causes the issue?
> 
> You should be able to access now, sent and invite

Thanks, got it. Attempting to reproduce now.

Comment 14

[cajbir (:cajbir)]

(In reply to bhargavg1 from comment #9)
> Gecko: 5ef3535021286ccab7af639897feaaf5955720a0

What repository is this hash from? From my 'gecko' directory that resulted from a "./config.sh unagi", this commmit ID doesn't exist. Am I doing something wrong?

Comment 15

[cajbir (:cajbir)]

(In reply to Chris Double (:doublec) from comment #14)
> (In reply to bhargavg1 from comment #9)
> > Gecko: 5ef3535021286ccab7af639897feaaf5955720a0
> 
> What repository is this hash from? From my 'gecko' directory that resulted
> from a "./config.sh unagi", this commmit ID doesn't exist. Am I doing
> something wrong?

n/m worked it out. That's a Gaia commit and the commit labeled as Gecko is the gaia one.

Comment 16

[bhargavg1]

(In reply to Chris Double (:doublec) from comment #15)
> (In reply to Chris Double (:doublec) from comment #14)
> > (In reply to bhargavg1 from comment #9)
> > > Gecko: 5ef3535021286ccab7af639897feaaf5955720a0
> > 
> > What repository is this hash from? From my 'gecko' directory that resulted
> > from a "./config.sh unagi", this commmit ID doesn't exist. Am I doing
> > something wrong?
> 
> n/m worked it out. That's a Gaia commit and the commit labeled as Gecko is
> the gaia one.

oops Sorry for the copy/paste error

Comment 17

[Thomas Zimmermann [:tzimmermann] [:tdz]]

Attachment: 0001-Bug-924678-Explicitly-clear-OmxDecoder-mDecoder-r-do.patch

I finally managed to reproduce the problem. Could you test the attached fix? It's from bug 924678 and seems to work for me.

Comment 18

[bhargavg1]

(In reply to Thomas Zimmermann [:tzimmermann] [:tdz] from comment #17)
> Created attachment 818946 [details] [diff] [review]
> 0001-Bug-924678-Explicitly-clear-OmxDecoder-mDecoder-r-do.patch
> 
> I finally managed to reproduce the problem. Could you test the attached fix?
> It's from bug 924678 and seems to work for me.

Yes works for me too. Don't see the crash anymore

Comment 19

[bhargavg1]

(In reply to Thomas Zimmermann [:tzimmermann] [:tdz] from comment #17)
> Created attachment 818946 [details] [diff] [review]
> 0001-Bug-924678-Explicitly-clear-OmxDecoder-mDecoder-r-do.patch
> 
> I finally managed to reproduce the problem. Could you test the attached fix?
> It's from bug 924678 and seems to work for me.

Is this issue only specific to VBR clips dont see this issue for regular mp3 clips?

Comment 20

[cajbir (:cajbir)]

Is it the case that uplifting bug 924678 to 1.2 fixes this?

Comment 21

[Thomas Zimmermann [:tzimmermann] [:tdz]]

Yes, bug 924678 seems to fix the problem.

Comment 22

[Thomas Zimmermann [:tzimmermann] [:tdz]]

Hi

(In reply to bhargavg1 from comment #18)
> (In reply to Thomas Zimmermann [:tzimmermann] [:tdz] from comment #17)
> > Created attachment 818946 [details] [diff] [review]
> > 0001-Bug-924678-Explicitly-clear-OmxDecoder-mDecoder-r-do.patch
> > 
> > I finally managed to reproduce the problem. Could you test the attached fix?
> > It's from bug 924678 and seems to work for me.
> 
> Yes works for me too. Don't see the crash anymore

Bug 924678 has been uplifted into 1.2. Maybe you can do another test, and then close this bug as duplicate? Thanks.

Comment 23

[bhargavg1]

will mark as duplicate of bug 924678, if we see any issues shall re-open this again

Comment 25

[bhargavg1]

(In reply to Thomas Zimmermann [:tzimmermann] [:tdz] from comment #22)
> Hi
> 
> (In reply to bhargavg1 from comment #18)
> > (In reply to Thomas Zimmermann [:tzimmermann] [:tdz] from comment #17)
> > > Created attachment 818946 [details] [diff] [review]
> > > 0001-Bug-924678-Explicitly-clear-OmxDecoder-mDecoder-r-do.patch
> > > 
> > > I finally managed to reproduce the problem. Could you test the attached fix?
> > > It's from bug 924678 and seems to work for me.
> > 
> > Yes works for me too. Don't see the crash anymore
> 
> Bug 924678 has been uplifted into 1.2. Maybe you can do another test, and
> then close this bug as duplicate? Thanks.

With the clip mentioned in Description see that the timeline shown isn't correct, first we calculate the time as 04:54 and when the clip reaches to 02:54 we stop playing updating our time to be 04:54. Can you please check this on the latest builds

Comment 26

[bhargavg1]

Will raise a new bug for this

Comment 27

[Chris Pearce [:cpearce (Not reading bugmail)]]

(In reply to bhargavg1 from comment #25)
> With the clip mentioned in Description see that the timeline shown isn't
> correct, first we calculate the time as 04:54 and when the clip reaches to
> 02:54 we stop playing updating our time to be 04:54. Can you please check
> this on the latest builds

Please CC myself and Edwin Flores on your new bug when you create it please bhargavg1, and make sure you include steps to reproduce the problem, and a link to a file which exhibits this problem.

Edwin is working on improving the duration estimate in bug 918135. He's determined that most MP3 players are able to estimate the duration by reading metadata tags and/or data in the first frame. So we should soon have a more accurate MP3 duration that doesn't change as we read more MP3 frames.