GNOME Bugzilla – Bug 589849
[segment] Clipping fails to handle start=stop<segment_start correctly
Last modified: 2009-08-11 11:04:39 UTC
I'm playing a theora/flac video, and doing a seek to the end of the file with: gst_element_seek (priv->playbin, 1.0, GST_FORMAT_TIME, GST_SEEK_FLAG_FLUSH, GST_SEEK_TYPE_SET, position, 0, 0); where position is the duration of the video. * This works with the trio gstreamer git/gst-plugins-base git/gst-plugins-good 0.10.14 * It segfaults with the trio gstreamer git/gst-plugins-base git/gst-plugins-good 0.10.15 * It segfaults with the trio gstreamer git/gst-plugins-base git/gst-plugins-good git So, if I haven't mix things with the git checkouts and make installs it means the regression is due to a change in pulsesink, introduced between 0.10.14 and 0.10.15. (yes, ready for a git bisect, will do it later) The segfault has the following backtrace. Program received signal SIGSEGV, Segmentation fault.
+ Trace 216639
Thread 2989403024 (LWP 865)
Interestingly git bisect points to a change in flacdec: commit a7902054bdbe4229a50a5d73843526fc21dc0c2f Author: Thomas Vander Stichele <thomas (at) apestaart (dot) org> Date: Sat Feb 21 12:47:00 2009 +0100 respect DEFAULT segment by clipping the last buffer to be sent and indeed commenting the change introduced in that commit "fixes" the segfault in pulsesink. so gstreamer git / gst-plugins-base git / gst-plugins-good git + a7902054bdbe4229a50a5d73843526fc21dc0c2f works-for-me
I meant: so gstreamer git / gst-plugins-base git / gst-plugins-good git + a7902054bdbe4229a50a5d73843526fc21dc0c2f *reverted* works-for-me
Any idea why? Also flacdec should use gst_audio_buffer_clip() which handles the clipping for TIME and DEFAULT format and also before the beginning of the segment. Could you check if flacdec writes to invalid memory location when clipping by using valgrind? In any case, this should be fixed before next -good release.
I can't reproduce this here with latest GIT... can you reproduce it?
Yes, I can reproduce it with latest git. I'll try to run valgrind on it as you suggested and understand a bit better what could go wrong. Unfortunately spare time is really hard to find these days.
Can you provide a sample file and sample code that shows this behaviour? I've tried really hard to reproduce this :)
Sure, here it is http://damien.lespiau.name/files/temp/878f969df5a65983d9f40018739e6d98/big-buck-bunny.ogv I'm sorry to not be able to test/debug this further in a timely fashion, I'm really busy right now. Thanks for trying hard to reproduce it! Some notes: * I'm actually playing this with clutter-gst which using a thin layer on top of playbin. I did not review the code that was written something like 2 years but will do as the new clutter-gst "maintainer". So a bug and/or arbitrary memory corruption could come from clutter-gst. I would say it's quite unlikely. * I'll write a simple test case trying to reproduce it.
Sebastian: you marked this as blocker for the upcoming release. Have you been able to reproduce the issue yet? Is anyone looking into this or working on a fix?
I wasn't able to reproduce it yet but someone should definitely look at it I guess. I'll try with the linked ogv file later.
Yes, I can confirm this bug with the big-buck-bunny file...
...but it happens with the latest core/base/good releases too unfortunately so it's at least no regression in gst-plugins-good. Maybe some basesink/audiosink/ringbuffer change in 0.10.24 has broken this...
This is apparently a bug in baseaudiosink, proposed patch follows.
Created attachment 140420 [details] [review] baseaudiosink-render-empty-buffer.diff Problem here is, that the buffer has data==NULL, 0 duration but a start timestamp. baseaudiosink doesn't notice that data==NULL, syncs (i.e. data += something) and then tries to commit this into the pulse ringbuffer.
Created attachment 140421 [details] [review] gstsegment-clip.diff This seems to be the real problem. gst_segment_clip() in baseaudiosink should drop the buffer even if start = stop < segment_start.
commit ca8a0376c5dda9aad1c726190585ba175160db4e Author: Sebastian Dröge <sebastian.droege@collabora.co.uk> Date: Tue Aug 11 12:59:13 2009 +0200 gstsegment: Clipping should detect start=stop<segment_start as outside the s Before it returned that [start,stop] is inside the segment and that the difference between segment_start and start needs to be clipped. If the clipping is done on a buffer (like in baseaudiosink) this will result in the data pointer being at a invalid memory position. Fixes bug #589849.