You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The result is that neither branch is entered, because stream->doStop changed in the middle. Depending on how the compiler compiles this code (and debug vs optimized will certainly be different) this can cause a race condition.
Since enqueue() hasn't been called and the code entered neither of the branches, it will iterate again.
Then it will enter sem_wait( &stream->outputSem ); and never wake up again; because enqueue was not called.
To Reproduce
I don't have a repro because this is theoretical. But it should be possible to create a tight loop or play/pause that tries to create the necessary conditions.
Describe the bug
I have not encountered this bug, but during my analysis of #15 I noticed this race condition.
StreamProcessingCallback performs the following:
Sequentially, it makes sense: If framesProcessed == 0 it means the callback has requested to stop/abort.
That means enqueue() hasn't been called.
However the problem is that the following execution is possible (assume
framesProcessed = 0
):The result is that neither branch is entered, because stream->doStop changed in the middle. Depending on how the compiler compiles this code (and debug vs optimized will certainly be different) this can cause a race condition.
Since enqueue() hasn't been called and the code entered neither of the branches, it will iterate again.
Then it will enter
sem_wait( &stream->outputSem );
and never wake up again; because enqueue was not called.To Reproduce
I don't have a repro because this is theoretical. But it should be possible to create a tight loop or play/pause that tries to create the necessary conditions.
Solution
Expected behavior
Actual behavior
Desktop (please complete the following information):
Additional context
The text was updated successfully, but these errors were encountered: