614136 - Hang in sa_stream_write on shutdown when IPC enabled due to stream being paused

Status: VERIFIED FIXED

(Core :: Audio/Video, defect)

Description

[Matthew Gregan [:kinetik]]

I just hit a shutdown hang where we're stuck in sa_stream_write where snd_pcm_writei returns 0 frames written.  The stream has previously been paused, and the don't-write-if-paused assertions in nsAudioStream.cpp fired.  It looks like having mPaused in the remote/child process is not sufficient to avoid this.

Comment 1

[Matthew Gregan [:kinetik]]

Easy to reproduce: pause and unpause a few times, eventually you'll hit the assertion.  The browser will hang in shutdown after this.

The problem is that the Write events are requeued on gAudioPlaybackThread after being received over IPC on the main thread.  Pause/Resume requests (because they're not blocking), run directly from the main thread.  So the following ordering causes this problem:

Remote: Send Write
Remote: Send Pause
Local: Recv Write
  -> Queue WriteEvent
Local: Recv Pause
 -> Local: Pause
Local: Write

We can fix this by shunting all of the Local Receives to gAudioPlaybackThread, or by having the Local::Write return an error if mPaused is already set.  The same event reordering problem happens for shutdown, but Local::Write is protected by mInError for that case already.

Comment 2

[Matthew Gregan [:kinetik]]

Bug 614160 contains a minimal fix for this: shunt pause/resume calls to the same thread used for write.

Comment 3

[Matthew Gregan [:kinetik]]

This was fixed by bug 614160.

Comment 4

[u279076]

Is there a way I can verify this bug?

Comment 5

[Matthew Gregan [:kinetik]]

In Fennec, start a video element playing, then click play/pause repeatedly, then close the browser.  Verify that the browser has shutdown completely.

Comment 6

[u279076]

Verified using the desktop simulator.  I don't have a fennec-capable device; someone might want to verify it that way.