[Webkit-unassigned] [Bug 201388] [GStreamer] Crash involving SourceBufferPrivateGStreamer

[bugzilla-daemon at webkit.org]

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

--- Comment #2 from Alicia Boya García <aboya at igalia.com> ---
Unfortunately the provided traceback is not very useful. There are many regions without symbols, and those where they were found, it's not clear how that call stack can even be happening.

#18 0x00007f707a772a20 in WTF::GRefPtr<_GMainLoop>::~GRefPtr() (this=<synthetic pointer>, __in_chrg=<optimized out>) at ../Source/WTF/wtf/glib/GRefPtr.h:74
        ptr = 0x0
        lastMainLoop = {m_ptr = 0x0}

If ptr was really zero there would be no inner calls:

    ~GRefPtr()
    {
        if (T* ptr = m_ptr)
            derefGPtr(ptr);
    }

The only explanation for that is that it was optimized out but the debugger was unable to mark it as such... or the stack was corrupted.

#15 0x00007f707d1cd15f in HashTableValuesIterator<HashTable<AtomString, KeyValuePair<AtomString, SourceBuffer::TrackBuffer>, [...]>::
operator++() (this=<synthetic pointer>) at DerivedSources/ForwardingHeaders/wtf/HashIterators.h:157
#16 0x00007f707d1cd15f in WebCore::SourceBuffer::setTimestampOffset(double) (this=<optimized out>, offset=6.9175979694419147e-310) at ../Source/WebCore/Modules/mediasource/SourceBuffer.cpp:186
#17 0x00007ffc0fb725d0 in  ()
#18 0x00007f707a772a20 in WTF::GRefPtr<_GMainLoop>::~GRefPtr() (this=<synthetic pointer>, __in_chrg=<optimized out>) at ../Source/WTF/wtf/glib/GRefPtr.h:74

That GMainLoop unref' somehow ends up triggering SourceBuffer::setTimestampOffset(), which is the first MSE piece of code here. In particular, it has to be crashing while traversing this iterator, since it's the only one in that function:

    for (auto& trackBuffer : m_trackBufferMap.values()) {
        [...]
    }

So far so good, but then this happens...

#7  0x00007f707e2538f2 in WTF::Vector<_GstAppSrc*>::expandCapacity(unsigned long) (this=0x7f707e24f323 <MediaSourceClientGStreamerMSE::append(RefPtr<SourceBufferPrivateGStreamer>, Vector<unsigned char>&&)+227>, newMinCapacity=<optimized out>) at DerivedSources/ForwardingHeaders/wtf/Vector.h:327
#8  0x00007f702411cf30 in  ()
#9  0x00007f702411d080 in  ()
#10 0x00007f707d1cd15f in HashTable<AtomString, KeyValuePair<AtomString, SourceBuffer::TrackBuffer>, [...]>::isEmptyOrDeletedBucket(KeyValuePair<AtomString, SourceBuffer::TrackBuffer> const&) (value=...) at DerivedSources/ForwardingHeaders/wtf/text/WTFString.h:367
[more HashMap iterator internals]

How come advancing an iterator causes a Vector<GstAppSrc*> to expand capacity? That makes absolutely no sense. And the `this` argument of that call makes even less sense! It's not even a vector, but a pointer to the program code.

The most plausible explanation for a stack like this is a stack corruption. Unfortunately by the time the program crashes it's already late to see the culprit. If you can get an asan traceback where the actual corruption occurs, that would be actually helpful.

-- 
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/20190902/a6d4d2cc/attachment.html>