After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 692145 - Crash when calling gst_element_set_state(playBin, GST_STATE_NULL)
Crash when calling gst_element_set_state(playBin, GST_STATE_NULL)
Status: RESOLVED INCOMPLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
1.0.5
Other Linux
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-01-20 17:54 UTC by Christophe Dumez
Modified: 2015-02-24 12:30 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Backtrace with symbols for all threads (17.66 KB, text/plain)
2013-01-20 17:54 UTC, Christophe Dumez
Details
Media file loaded by the test (188.32 KB, video/mp4)
2013-01-20 18:00 UTC, Christophe Dumez
Details
Full valgrind log (149.13 KB, text/x-log)
2013-01-20 18:54 UTC, Christophe Dumez
Details
Log with GST_DEBUG=6 (122.16 KB, application/x-bzip)
2013-01-21 13:26 UTC, Christophe Dumez
Details
gdb backtrace (19.04 KB, text/plain)
2013-01-23 07:46 UTC, Jussi Kukkonen
Details
full gdb backtrace for the offending thread (25.30 KB, text/plain)
2013-01-23 07:47 UTC, Jussi Kukkonen
Details

Description Christophe Dumez 2013-01-20 17:54:09 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.
Comment 1 Christophe Dumez 2013-01-20 18:00:46 UTC
Created attachment 233953 [details]
Media file loaded by the test
Comment 2 Tim-Philipp Müller 2013-01-20 18:13:02 UTC
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?
Comment 3 Christophe Dumez 2013-01-20 18:39:48 UTC
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.
Comment 4 Christophe Dumez 2013-01-20 18:54:20 UTC
Created attachment 233960 [details]
Full valgrind log

As you can see from this full valgrind log, we are getting a SIGSEGV.
Comment 5 Tim-Philipp Müller 2013-01-20 20:07:29 UTC
Thanks!
Comment 6 Christophe Dumez 2013-01-21 13:26:25 UTC
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.
Comment 7 Jussi Kukkonen 2013-01-23 07:46:21 UTC
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.
Comment 8 Jussi Kukkonen 2013-01-23 07:47:56 UTC
Created attachment 234171 [details]
full gdb backtrace for the offending thread
Comment 9 Jussi Kukkonen 2013-01-23 09:02:44 UTC
(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:

  • #0 raise
    from /lib/x86_64-linux-gnu/libc.so.6
  • #1 abort
    from /lib/x86_64-linux-gnu/libc.so.6
  • #2 ??
    from /lib/x86_64-linux-gnu/libc.so.6
  • #3 ??
    from /lib/x86_64-linux-gnu/libc.so.6
  • #4 ??
    from /lib/x86_64-linux-gnu/libc.so.6
  • #5 free
    from /lib/x86_64-linux-gnu/libc.so.6
  • #6 av_freep
    at libavutil/mem.c line 150
  • #7 free_tables
    at libavcodec/h264.c line 865
  • #8 ff_h264_free_context
    at libavcodec/h264.c line 4290
  • #9 ff_h264_decode_end
    at libavcodec/h264.c line 4304

I both cases it's trying to free stuff in the MpegEncContext inside the H264Context.
Comment 10 Jussi Kukkonen 2013-01-23 09:28:25 UTC
I can reproduce this with other mpeg4 files, but cannot reproduce with a theora file. So it does seem connected to the decoder.
Comment 11 Tim-Philipp Müller 2013-01-23 09:46:15 UTC
Could you get  stack trace of all threads at the time of crash by any chance? (thread apply all bt)
Comment 12 Jussi Kukkonen 2013-01-23 09:55:29 UTC
(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
Comment 13 Sebastian Dröge (slomo) 2013-08-16 10:20:57 UTC
Is this still a problem with 1.0.9 or latest git master? I remember fixing something similar to this
Comment 14 Tim-Philipp Müller 2015-02-24 12:30:20 UTC
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!