1374956 - Enable dom/media/test/test_playback_rate.html on Android

Status: RESOLVED INCOMPLETE

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

Description

[Alastor Wu [:alwu]]

TEST-UNEXPECTED-FAIL | dom/media/test/test_playback_rate.html | very-short.mp3-5 timed out!

Comment 1

[Alastor Wu [:alwu]]

Hi, John,
When I reproduced it on local, I saw the following exception.
Do you have any idea? it's reasonable?
Not sure it's related or not, I'll investigate for more details.

06-21 16:23:38.179 14993 15003 E StrictMode: A resource was acquired at attached stack trace but never released. See java.io.Closeable for information on avoiding resource leaks.
06-21 16:23:38.179 14993 15003 E StrictMode: java.lang.Throwable: Explicit termination method 'close' not called
06-21 16:23:38.179 14993 15003 E StrictMode: 	at dalvik.system.CloseGuard.open(CloseGuard.java:180)
06-21 16:23:38.179 14993 15003 E StrictMode: 	at android.os.ParcelFileDescriptor.<init>(ParcelFileDescriptor.java:181)
06-21 16:23:38.179 14993 15003 E StrictMode: 	at android.os.ParcelFileDescriptor.<init>(ParcelFileDescriptor.java:170)
06-21 16:23:38.179 14993 15003 E StrictMode: 	at android.os.Parcel.readFileDescriptor(Parcel.java:1695)
06-21 16:23:38.179 14993 15003 E StrictMode: 	at org.mozilla.gecko.mozglue.SharedMemory.<init>(SharedMemory.java:36)
06-21 16:23:38.179 14993 15003 E StrictMode: 	at org.mozilla.gecko.mozglue.SharedMemory.<init>(SharedMemory.java:17)
06-21 16:23:38.179 14993 15003 E StrictMode: 	at org.mozilla.gecko.mozglue.SharedMemory$1.createFromParcel(SharedMemory.java:44)
06-21 16:23:38.179 14993 15003 E StrictMode: 	at org.mozilla.gecko.mozglue.SharedMemory$1.createFromParcel(SharedMemory.java:41)
06-21 16:23:38.179 14993 15003 E StrictMode: 	at android.os.Parcel.readParcelable(Parcel.java:2367)
06-21 16:23:38.179 14993 15003 E StrictMode: 	at org.mozilla.gecko.media.SharedMemBuffer.<init>(SharedMemBuffer.java:23)
06-21 16:23:38.179 14993 15003 E StrictMode: 	at org.mozilla.gecko.media.SharedMemBuffer$1.createFromParcel(SharedMemBuffer.java:39)
06-21 16:23:38.179 14993 15003 E StrictMode: 	at org.mozilla.gecko.media.SharedMemBuffer$1.createFromParcel(SharedMemBuffer.java:36)
06-21 16:23:38.179 14993 15003 E StrictMode: 	at android.os.Parcel.readParcelable(Parcel.java:2367)
06-21 16:23:38.179 14993 15003 E StrictMode: 	at org.mozilla.gecko.media.Sample.<init>(Sample.java:118)
06-21 16:23:38.179 14993 15003 E StrictMode: 	at org.mozilla.gecko.media.Sample.<init>(Sample.java:20)
06-21 16:23:38.179 14993 15003 E StrictMode: 	at org.mozilla.gecko.media.Sample$1.createFromParcel(Sample.java:184)
06-21 16:23:38.179 14993 15003 E StrictMode: 	at org.mozilla.gecko.media.Sample$1.createFromParcel(Sample.java:181)
06-21 16:23:38.179 14993 15003 E StrictMode: 	at org.mozilla.gecko.media.ICodecCallbacks$Stub.onTransact(ICodecCallbacks.java:79)
06-21 16:23:38.179 14993 15003 E StrictMode: 	at android.os.Binder.execTransact(Binder.java:453)

Comment 2

[Alastor Wu [:alwu]]

Even the decoding state has been changed to "Completed", the |mMaster->mAudioCompleted| doesn't be changed.
That causes the mdsm won't call StopPlayback().

Comment 3

[Alastor Wu [:alwu]]

It seems that the Android audio backend doesn't set the state to CUBEB_STATE_DRAINED, so we always won't reach the end.

Comment 4

[Alastor Wu [:alwu]]

Attachment: Timeout log when playing very-short.mp3, test_playback_rate.html

The problem might be in the cubeb, and I observed there are two strange points.

The first one is the AudioStream::Datacallback() would happen before we started the audio stream, the case is similar with bug1286041.

The second one is cubeb never calls drain() for us, we can't receive CUBEB_STATE_DRAINED via StateCallback().

The AudioStream would only mark itself as ended after cubeb calling drain or we call shutdown explicit. Therefore, we won't ended the playback even we have played all decoded samples if cubeb doesn't call drain.

That is the root cause why we would get this timeout.

---

Here is the log when we got this timeout failure.
I'll open another bug for the cubeb problem and checking whether we can enable this test after fixing that bug.

Comment 5

[Alastor Wu [:alwu]]

Hmm...I can reproduce it via running mochitest on Nexus5 and Z3C, but I can't reproduce the symptom when we play that file directly instead of running mochitest.

Need to investigate more details.

Comment 6

[Alastor Wu [:alwu]]

(In reply to Alastor Wu [:alwu][please needinfo? me] from comment #5)
> Hmm...I can reproduce it via running mochitest on Nexus5 and Z3C, but I
> can't reproduce the symptom when we play that file directly instead of
> running mochitest.

Stupid, I forgot to change the playback rate when playing the file directly.
This issue happen when the file playback rate change, but it won't happen on other files, only happen on "very-short.mp3".

Comment 7

[John Lin [:jhlin][:jolin]]

The "A resource was acquired at attached stack trace but never released" message could happen if process is killed when audio is still playing and without shutting down decoder properly. Doesn't seem related to this bug.

Comment 8

[Alastor Wu [:alwu]]

Hi, John,
But this message is displayed when we're playing audio, the process is still alive.
I'm wondering whether it's related with the leak issue?
Thanks!

Comment 9

[Alastor Wu [:alwu]]

I guess that "test_playback_rate_playpause.html" is also the same problem.

Comment 10

[Alastor Wu [:alwu]]

(In reply to Alastor Wu [:alwu][please needinfo? me] from comment #9)
> I guess that "test_playback_rate_playpause.html" is also the same problem.

It might affect all tests which use gPlayedTests, I saw the same symptom on "test_played.html".

Comment 11

[Alastor Wu [:alwu]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=320ce16961f94cf3371eea9d9c303be7e8963b5b

Comment 12

[Alastor Wu [:alwu]]

From the result on comment11, we can enable the test again.

Comment 13

[Alastor Wu [:alwu]]

Also try to enable other tests which also changes the playback rate, let's waiting for result.
https://treeherder.mozilla.org/#/jobs?repo=try&revision=1c01cd5e667fe850cfbaf23e20e90f6e6d55ae81

Comment 14

[BMO Automation]

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.