1158307 - crash in mozilla::MediaTaskQueue::Dispatch(already_AddRefed<nsIRunnable>, mozilla::AbstractThread::DispatchFailureHandling, mozilla::AbstractThread::DispatchReason) Crash in Music when tapping Next through several songs rapidly.

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::Music, defect)

Description

[Martin Shuman [:Marty]]

Attachment: logcat-Music-Crash.txt

This bug was filed from the Socorro interface and is 
report bp-62e4c89e-ca1d-41d0-be01-b02282150424.
=============================================================

Description:
If the user taps Next through several songs in a playlist, the music app will close out, generating a crash report.

Note: This issue seems to require fairly specific timing. Tapping 'Next' too fast or too slow will not reproduce this issue. The timing seems to require that the user tap next just as the song finshes loading up.

Prerequisite: Have at least 10 music tracks on the device.

Repro Steps:
1) Update a Flame to 20150424010200
2) Launch the Music app.
3) Navigate to the Songs tab
4) Select the First song
5) Tap next several times, just as each song loads up

Actual:
The music app crashes

Expected:
The music app does not crash, remains performant

Environmental Variables:
Device: Flame 3.0 (319MB)(Full Flash)
Build ID: 20150424010200
Gaia: 0c5e2ee1173f3c53379ef3cd10de714836258fe8
Gecko: 22a157f7feb7
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 40.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0

Repro frequency: 6/6
See attached: Logcat, Video (URL)

Comment 1

[Martin Shuman [:Marty]]

I have not been able to reproduce this crash in the latest Flame 2.2 build.
Music app does not crash, and remains performant.

Environmental Variables:
Device: Flame 2.2 (319MB)(Full Flash)
Build ID: 20150423002502
Gaia: b838d0e7c163e66660dcb6e387d8339944a7a30e
Gecko: 8dce56574f28
Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429
Version: 37.0 (2.2)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Comment 2

[Peter Bylenga [:PBylenga]]

[Blocking Requested - why for this release]:
Regression resulting in a reproducible crash.

Requesting a window.

Comment 3

[Yeojin Chung [:YeojinC]]

Mozilla-inbound Regression Window:

Last Working Environmental Variables:
Device: Flame 3.0
BuildID: 20150415215323
Gaia: 629097847567e51095a454e7e63186a6e2ac0307
Gecko: d81efb572537
Version: 40.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0

First Broken Environmental Variables:
Device: Flame 3.0
BuildID: 20150415223626
Gaia: 629097847567e51095a454e7e63186a6e2ac0307
Gecko: 8e0a4a2295f8
Version: 40.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0

Last Working Gaia First Broken Gecko: Issue DOES reproduce 
Gaia: 629097847567e51095a454e7e63186a6e2ac0307
Gecko: 8e0a4a2295f8

First Broken Gaia Last Working Gecko: Issue does NOT reproduce
Gaia: 629097847567e51095a454e7e63186a6e2ac0307
Gecko: d81efb572537

http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=d81efb572537&tochange=8e0a4a2295f8

possibly caused by bug 1154782

Comment 4

[KTucker [:KTucker][Inactive 3/4/2016]]

Bobby, can you take a look at this please? This might have been caused by the landing for bug 1154782.

Comment 5

[Bobby Holley (:bholley)]

(In reply to KTucker [:KTucker] from comment #4)
> Bobby, can you take a look at this please? This might have been caused by
> the landing for bug 1154782.

In a sense, yes. In that bug I added machinery to assert that AbstractThread/MediaTaskQueue dispatch always succeeds unless the caller indicates it may fail. This stack suggests that it's failing somewhere.

Given that this appears to be b2g-only and the dispatch is happening on the main thread, my bet is that we're looking at the dispatch in MediaOmxCommonDecoder::{Pause,Resume}StateMachine. But somebody with a debugging setup that can reproduce this should confirm by breaking at the assertion site and seeing if the runnable points to &MediaDecoderStateMachine::SetDormant.

Sotaro, are you the right person to do that?

Comment 6

[Sotaro Ikeda [:sotaro]]

Okey, I take a look.

Comment 7

[Sotaro Ikeda [:sotaro]]

I confirmed to reproduce the problem.

Comment 8

[Sotaro Ikeda [:sotaro]]

The problem happened when MediaOmxCommonDecoder::FirstFrameLoaded() was called after MediaDecoder::Shutdown().

Comment 9

[Sotaro Ikeda [:sotaro]]

Attachment: patch - Add Shutdown checks

The patch seems to fix the problem for me.

Comment 10

[Sotaro Ikeda [:sotaro]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/fb882ba2e7cb

Comment 11

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/fb882ba2e7cb

Comment 12

[Martin Shuman [:Marty]]

This issue is verified fixed on the latest Aries and Flame 2.5 builds.
After over 20 attempts on each device, I was unable to reproduce this crash on by skipping tracks rapidly in the music app. The music app properly remained performant.

Environmental Variables:
Device: Aries 2.5
Build ID: 20150806112625
Gaia: 497fe3f938722b0aa49c93f975fad5d9ed3b0a82
Gecko: 22476236b3e1
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 42.0a1 (2.5)
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0

Environmental Variables:
Device: Flame 2.5
BuildID: 20150806030207
Gaia: 4ede0c6bf5fb0c2896d5393032b395999a154619
Gecko: 07befc6f54e7
Gonk: 41d3e221039d1c4486fc13ff26793a7a39226423
Version: 42.0a1 (2.5) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0