1194995 - crash in libsomxcore.so@0x1826 on start-up when session restore is restoring a tab with a local MP3 file

Status: RESOLVED WORKSFORME

(Firefox for Android Graveyard :: Audio/Video, defect, P1)

Description

[Jan Henning [:JanH]]

This bug was filed from the Socorro interface and is 
report bp-6f9149bb-3df6-446b-b064-ccd492150815.
=============================================================

STR:
1. Make sure Settings -> Customize -> Tabs is set to "Always restore"
2. I've mostly tested with Allow autoplay enabled, although I've experienced the crash even with it disabled.
2. Open a local MP3 file from your device (like e.g. /storage/extSdCard/Music/SomeRandomFile.mp3)
3. Switch away from Firefox and kill the process by swiping it away in the task switcher.
4. Start Firefox again.

Outcome:
Session restore will restore your tabs, including the one containing the local MP3 file. Because the tab with the MP3 file is the currently selected tab, Firefox will start actually loading the MP3 file. Often (but not always), Firefox will crash during loading of that tab.

Additional remarks:
- If you open an additional tab and make it the active tab before switching away from Firefox, session restore will start restoring that tab instead, and leave the tab containing the MP3 file in the pending state. If you then switch to the MP3 tab, it will usually load normally without crashing Firefox, although somehow one time only I managed to crash Firefox that way, too.
- Using an MP3 file from the Internet doesn't crash Firefox, so maybe it's some sort of race condition which is exposed because loading a file from your device is much faster than loading it from the internet.

Test setup:
Samsung Galaxy S3 Mini, Android 4.1.2
current Nightly (build 20150815030208)

I've also tested on 41.0b1 with the same results, see e.g. bp-6240f6b4-e2de-4c11-ae11-5fdd32150815

On the current release version (FF40), the same STR are also crashing Firefox, but with two differences:
1. Crashing happens more reliably. This also means that this problem can cause a crash loop which can only be broken by deleting your sessionstore.js.
2. A different crash signature: [@ nsObserverService::AddObserver(nsIObserver*, char const*, bool)]

See bp-545c0c66-65e6-4eed-858e-b5d632150815 for an exemplary crash report.

Comment 1

[Jan Henning [:JanH]]

I don't know in how far that's related to the root cause of the above crashes, or if it should belong in a different bug, but I've noticed some crashes which, as far as I can discern, follow the general pattern of:

- I interact with some MP3 file, either by opening it directly, or via page with an HTML5 audio player
- I stop playback and close the tab. However because so far I haven't found a reliable way to reproduce these crashes, I can't remember whether I first stopped playback and then closed the tab, or whether I closed the tab directly, and also if I closed the tab at all in all cases.
- Some time later, Firefox crashes with a crash in libsomxcore.so@0x1826.

Comment 2

[Kevin Brosnan [Ex-Mozilla]]

Seems actionable.

Comment 3

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

Is this a duplicate of another bug?

Comment 4

[Eugen Sawin [:esawin]]

(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #3)
> Is this a duplicate of another bug?

Unclear, I can't reproduce it on the device.

Jan, can you still reproduce it on Nightly?

Comment 5

[Jan Henning [:JanH]]

No, I cannot reproduce it either. I think I managed one crash out of more than ten attempts on the current release version (44.0), but I don't know whether that signifies something or whether it simply happened by chance and could have equally happened on Nightly.

In any case I guess I can close this issue on that basis.