Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix race in ref/deref of StringImpl for some cases #1372

Open
wants to merge 2 commits into
base: wpe-2.38
Choose a base branch
from

Conversation

emutavchi
Copy link

This fixes some random use-after-free reported by ASAN (when destroying SourceBufferPrivateGStreamer) and by Ref/Deref threading check applied on StringImpl object.

  • first commit addresses the race between main and streaming thread on track id string refcount. WebKitMediaSourceGStreamer references trackId in streaming thread when creating stream id, when notifying of low buffer level and for debugging purposes. The lifetime of trackId is guarantied to outlive streaming thread, so it should be enough to avoid copying the trackId or create an isolated copy when needed.

  • second commit addresses potential problem with the copy of Nicosia Animation. The Ref/Deref check report that same string is shared between main and compositor threads.

The Ref/Deref threading check implementation is available here:
emutavchi@724ef45. It is not included in this PR because it brings some overhead and may give false positive results (so reports should be reviewed carefully).

…main thread

StringImpl's ref count in not thread safe.
The name StringImpl object can be shared with comositor thread
if animaton source object has name StringImpl with ref count 1 (and so
isSafeToSendToAnotherThread would return true). Which can lead to a
race in StingImpl ref/deref between main and compositor threads.
@modeveci modeveci removed the request for review from zdobersek August 7, 2024 13:37
@eocanha
Copy link
Member

eocanha commented Sep 30, 2024

Some of the code affected by this PR has changed upstream as part of the effort to use integer track ids in the long term. The referenced upstream change still keeps the string track ids, but there's ongoing work by @vivienne-w to fully migrate to integer ids.

This means that this PR, if approved, would be downstream only.

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

Successfully merging this pull request may close these issues.

3 participants