FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

Possible deadlock in AudioInputStreamOpenSLES::close() · Issue #1062 · google/oboe · GitHub

/ oboe Public

Possible deadlock in AudioInputStreamOpenSLES::close() #1062

Description

A third-party developer wrote in an email:

...we are suspecting there might be a deadlock in the OpenSL implementation of the close() method called on the Input stream, namely: AudioInputStreamOpenSLES::close(). While we aren’t currently able to repro the problem on any of our devices, our logs indicate that a large number of devices are timing out (take more than 10 secs) waiting on the call to return. This happens when both input and output streams are opened and we stop the input stream.

Our integration uses the latest public Oboe release and creates a managed stream and we simply call stream_->stop() followed by stream_-flush(). We know the thing deadlocks there because we fire an event when close returns and we don’t see this event in the cases we mention.

Here’s the top 10 devices that this occurs on:

[various Vivo and Redmi devices.]

And the top 3 Android versions:

  • Android 9
  • Android 8.1
  • Android 7

I noticed this in AudioInputStreamOpenSLES::close()

  mLock.unlock(); // avoid recursive lock
  requestStop();
  mLock.lock();

[We think] a race can occur here, right before and right after calling requestStop();

[Consider using] std::recursive_mutex

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

P1high prioritybug

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions


    Back | FazBrowse Home | New Git URL