GNOME Bugzilla – Bug 692145
Crash when calling gst_element_set_state(playBin, GST_STATE_NULL)
Last modified: 2015-02-24 12:30:20 UTC
Created attachment 233952 [details] Backtrace with symbols for all threads We sometimes experience crashes in WebKit when calling gst_element_set_state(playBin, GST_STATE_NULL). This started happening after we updated from gstreamer 0.10.36 to 1.0.5.
Created attachment 233953 [details] Media file loaded by the test
It's not clear to me which of those threads is supposed to have crashed. Is this really a crash, or rather a deadlock or ...? If a crash (SIGSEGV or so) - do you have the full valgrind log?
We usually see crashes such as this one: https://bugs.webkit.org/show_bug.cgi?id=106551#c7 with *** glibc detected *** /home/chris/unencrypted/WebKit/WebKitBuild/Debug/bin/WebProcess: corrupted double-linked list: 0x00007f449421db60 *** I cannot seem to reproduce the issue in gdb yet and I'll try to get the full valgrind log.
Created attachment 233960 [details] Full valgrind log As you can see from this full valgrind log, we are getting a SIGSEGV.
Thanks!
Created attachment 234005 [details] Log with GST_DEBUG=6 I got a log with GST_DEBUG=6. The error is slightly different (GStreamer-WARNING **: loop detected in the graph of bin 'decodebin24'!!) but the backtrace seems to be the same. I'm attaching in case it helps.
Created attachment 234170 [details] gdb backtrace I can reproduce this in gdb with the webkit-efl minibrowser (a simple test web browser). Normally loading the page and reloading goes fine, but if I reloading fast enough it crashes (sometimes it takes a while, sometimes it just needs two quick refreshes). The is leads me to think that something in the stack does not cope with us setting the state to GST_STATE_NULL at some specific point of the element life cycle. The backtrace does not look 100% like the one Christophe attached, I'm not sure if these should be separate bugs: but mine at least looks 'clearer': It crashes in thread 1 in gst_memory_unmap() because the ffmpeg decoder tries to free some video frames.
Created attachment 234171 [details] full gdb backtrace for the offending thread
(In reply to comment #7) > The backtrace does not look 100% like the one Christophe attached, I'm not sure > if these should be separate bugs: but mine at least looks 'clearer': It crashes > in thread 1 in gst_memory_unmap() because the ffmpeg decoder tries to free some > video frames. There's another version of this that looks the same until ff_h264_decode_end(), but from then on it's:
+ Trace 231416
I both cases it's trying to free stuff in the MpegEncContext inside the H264Context.
I can reproduce this with other mpeg4 files, but cannot reproduce with a theora file. So it does seem connected to the decoder.
Could you get stack trace of all threads at the time of crash by any chance? (thread apply all bt)
(In reply to comment #11) > Could you get stack trace of all threads at the time of crash by any chance? > (thread apply all bt) Comment 7 should have that, let me know if I'm still missing something
Is this still a problem with 1.0.9 or latest git master? I remember fixing something similar to this
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment. Thanks!