Make sure FilterAudioStream is alive in callbacks (#2325)

[jg-hot]

This modifies AAudioStreamCollection.getStream() to return a tuple which includes a shared_ptr to the parent stream if the AAudioStream is wrapped by a FilterAudioStream.

The child is linked to the parent via a raw pointer (AudioStream.getParentStream() / AudioStream.hasParentStream() and locked during callbacks with lockWeakThis().

The shared_ptr to the parent is passed to the callback threads (e.g. oboe_aaudio_error_thread_proc_shared) so its memory is retained until the callback thread finishes running.

See discussion under issue #2325 for more details.

Tested against the sample in FilterAudioStreamUAF-repro.

[jg-hot]

@flamme @robertwu1 could you please review this when you get a chance? I'm not able to add reviewers directly. Thanks.

[robertwu1]

LGTM @flamme please add comments if you have any. Thanks!

[flamme]

Q: this parent stream is a raw pointer, how it guarantees the parent stream is still alive when a callback arrive?

[jg-hot]

This relies on the same assumption that the AAudioStreamCollection uses for the child (AAudio) stream. That the client always calls close() before releasing their shared_ptr.

That ensures that callbacks are rejected if the stream is about to be released.

The parent should be alive as long as the child is. The ownership chain is shared_ptr client → FilterAudioStream → AudioStreamAAudio.

I don't see any case where the parent is freed but the child is not.

[flamme]

Isn't the root cause that the parent stream is gone while the child stream is still alive? The child stream received an error callback and call to parent's error callback, which was swapped in FilterAudioStream constructor.

[jg-hot]

In #2325 the parent is still alive at the moment of the callback (AudioStreamAAudio::internalErrorCallback(), call to getStream() here).

If what you're describing is possible (parent freed, but child is still alive in internalErrorCallback()), that would be a separate bug (but as mentioned above that shouldn't happen due to the ownership chain and AAudioStreamCollection returning isStreamAlive).

The root cause of the original bug is as follows (race condition):

• internalErrorCallback() runs. Memory is locked (only the child, before applying this fix), then a std::thread is created.
• Client releases their shared_ptr to the stream
• At some point in the future the thread is scheduled for execution and crashes here since only the child was retained.

The core idea of this fix is to simply pass an additional shared_ptr (parent) to the thread struct for oboe_aaudio_error_thread_proc_shared to fix the race. I.e. adding sharedParentStream here.