[Webkit-unassigned] [Bug 282396] New: Usage of AtomString in TrackPrivateBaseGStreamer is not thread-safe

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Oct 31 10:53:35 PDT 2024


https://bugs.webkit.org/show_bug.cgi?id=282396

            Bug ID: 282396
           Summary: Usage of AtomString in TrackPrivateBaseGStreamer is
                    not thread-safe
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKitGTK
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: aboya at igalia.com
                CC: bugs-noreply at webkitgtk.org

Currently TrackPrivateBaseGStreamer uses AtomString in these fields:

    AtomString m_label;
    AtomString m_language;
    AtomString m_stringId;

Additionally, AtomString is received and returned by several methods.

    const AtomString& stringId() const { return m_stringId; };
private:
    static AtomString generateUniquePlaybin2StreamID(TrackType, unsigned index);
    static TrackID trackIdFromStringIdOrIndex(TrackType, const AtomString&, unsigned);

Unfortunately, AtomString is not thread-safe in _at least_ two use cases.

Use case #1: AtomStrings created in one thread cannot be destroyed in another.

I saw this happen in imported/w3c/web-platform-tests/media-source/mediasource-sequencemode-append-buffer.html within a Debug build. It crashed inside the destructor of one of the AtomStrings of TrackPrivateBaseGStreamer, in this assert:

void AtomStringImpl::remove(AtomStringImpl* string)
{
// ...
    ASSERT_WITH_MESSAGE(iterator != atomStringTable.end(), "The string being removed is an atom in the string table of an other thread!");

Use case #2: The internal ref counting of AtomStrings is also not thread-safe, as found by Eugene: https://github.com/WebPlatformForEmbedded/WPEWebKit/pull/1372/commits/33bfbb48666b7de47041e021654894d840b51ff4

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20241031/50ece45b/attachment.htm>


More information about the webkit-unassigned mailing list