[Android][K44 Audio] AudioTrackShared mFutex deadlock

[eleven xiang]

Dear All,

firstly, I am sorry to trouble you for a Andriod Audio issue.

in AudioTrackShared.cpp, for a recording case, we met below issue:

recording case met overrun, so the inputThread will sleep a while, but AudioRecrodThread will continue to run and block at mCblk->mFutex.

if right now, user stop the recording, and the inputThread has no chance to release mFutext, then to standby.

And the client's interrupt was just called right before AudioRecordThread's obtainBbuffer try to wait mCblk->mFutex.

@@ -209,13 +209,18 @@ status_t ClientProxy::obtainBuffer(Buffer* buffer, const struct timespec *reques

         }

         int32_t old = android_atomic_and(~CBLK_FUTEX_WAKE, &cblk->mFutex);

         if (!(old & CBLK_FUTEX_WAKE)) {

            int rc;

             if (measure && !beforeIsValid) {

                 clock_gettime(CLOCK_MONOTONIC, &before);

                 beforeIsValid = true;

             }

            int ret = __futex_syscall4(&cblk->mFutex,

                    mClientInServer ? FUTEX_WAIT_PRIVATE : FUTEX_WAIT, old & ~CBLK_FUTEX_WAKE, ts);

Then we will find that AudioRecrodThread will always be blocked, because RecordTrack's destory will also miss the wake mCblk->mFutex, for it was already Interrupted before.

So I wonder why has below CBLC_INTERRUPT condition judgement before wake, Could we just remove it ?

void ClientProxy::interrupt()

{

    audio_track_cblk_t* cblk = mCblk;

    if (!(android_atomic_or(CBLK_INTERRUPT, &cblk->mFlags) & CBLK_INTERRUPT)) {

        (void) __futex_syscall3(&cblk->mFutex, mClientInServer ? FUTEX_WAKE_PRIVATE : FUTEX_WAKE,

                1);

    }

}

Thanks

[Glenn Kasten]

Eleven - Thank you for your post.

I could not figure out from your post what your exact code change is.

Can you please upload your CL to AOSP?

See https://source.android.com/source/submit-patches.html

It will be easier to review there.

Thanks

[eleven xiang]

Dear Glenn,

May be I didn't describe my issue clearly.

I mean this issue should be also exist in current 4.4 version, it wasn't caused by our modification.

our met issue case was a timing issue as below:

1. intputThread enter into sleep status, because client didn't retrieve data fast enough.

2. user stop the record action right at this time, so ClientProxy::interrupt() will be called when try to stop, and it will set CBLK_INTERRUPT and wake up mFutex.

void ClientProxy::interrupt()

{

    audio_track_cblk_t* cblk = mCblk;

    if (!(android_atomic_or(CBLK_INTERRUPT, &cblk->mFlags) & CBLK_INTERRUPT)) {

        (void) __futex_syscall3(&cblk->mFutex, mClientInServer ? FUTEX_WAKE_PRIVATE : FUTEX_WAKE,

                1);

    }

}

3. AudioRecordThread continue to run and block at  ClientProxy::obtainBuffer() when try to wait mCblk->mFutex right just after ClientProxy::interrupt() called.

status_t ClientProxy::obtainBuffer(Buffer* buffer, const struct timespec *requested,

        struct timespec *elapsed) {

        ...

        __futex_syscall4(&cblk->mFutex, mClientInServer ? FUTEX_WAIT_PRIVATE : FUTEX_WAIT, old & ~CBLK_FUTEX_WAKE, ts);

       ...

    }

4. because stop action, when inputThread come back, it will just enter standby() and will not call releaseBuffer to wake up AudioRecordThread

5. and RecordTrack destroy will call ClientProxy::interrupt() again, but because CBLK_INTERRUPT was already set by its stop() function before, so AudioRecordThread will still be blocked

So in bugreport we will see deadlock.

You could check the code in AudioTrack Shared.cpp file.

We want to remove the judgement in ClientProxy::interrupt().

let interrupt() didn't care about if it was interrupted before.

it just set the flag and wake up mFutex

But we has some concern, so we hope you could give me some suggestion.

Thanks

在 2014年10月14日星期二UTC+8下午1时35分01秒，eleven xiang写道：