GNOME Bugzilla – Bug 655887
gst_buffer_create_sub: assertion `buffer->size >= offset + size' failed
Last modified: 2012-02-18 20:13:04 UTC
I am hitting this assertion when playing, streaming or recording using dvbbasebin to access DVB-T streams. Command like: gst-launch -v dvbbasebin frequency=505833330 code-rate-hp=3/4 modulation="QAM 16" bandwidth=8 trans-mode=2k guard=32 hierarchy=0 code-rate-lp=3/4 program-numbers=4164 name=src .program_4164 src.program_4164 ! udpsink host=127.0.0.1 port=65501 Will fail sooner or later with: (gst-launch-0.10:27132): GStreamer-CRITICAL **: gst_buffer_create_sub: assertion `buffer->size >= offset + size' failed Caught SIGSEGV accessing address 0x14
+ Trace 228010
Unfortunately stack is corrupt so better back trace is not possible. I understand dvbbasebin is from bad plugins, however I am not certain whether it just triggers a bug in core code (gst_buffer_create_sub), nor do I know how to ascertain that. This is under Fedora 15 and bad + ugly plugins from rpmfusion.org. Bad plugins actually rebuilt from source RPM with a modified spec file to include dvbsuboverlay for DVB-T subtitles. But it probably does not matter since that plugin is not used in the above example.
Thanks for taking the time to report this bug. Without a stack trace from the crash it's very hard to determine what caused it. Can you get us a stack trace? Please see http://live.gnome.org/GettingTraces for more information on how to do so. Thanks in advance!
Oh, also: if you can reproduce the issue, maybe valgrind helps narrow it down (but you still should install debugging symbols for libc, glib2, gstreamer, gstreamer-plugins*)
No, as I said gdb reports stack as possibly corrupt: """ Backtrace stopped: previous frame inner to this frame (corrupt stack?) """ It is 100% reproducible, just the time for it to appear varies from minutes to an hour or so. I will try debug symbols and valgrind, if it will run with acceptable performance under it of course.
It's not a buffer in core code, it's a bug in the code that is calling that function (create_sub). You can set the G_DEBUG environment variable to fatal_warnings, then it should abort at the warning, and you can see exactly which line of code triggers it and why. e.g.: G_DEBUG=fatal_warnings gdb --args /usr/bin/gst-launch-0.10 ....yourpipeline... Note that you need to use "gst-launch-0.10" with gdb/valgrind, not "gst-launch".
I am running it under gdb at the moment waiting for bug to trigger. I had to remove the G_DEBUG like because stream of warnings like below was aborting it. (gst-launch-0.10:27336): GStreamer-WARNING **: Trying to set string on structure field 'description', but string is not valid UTF-8. Please file a bug. (gst-launch-0.10:27336): GStreamer-WARNING **: Trying to set string on structure field 'description', but string is not valid UTF-8. Please file a bug. I previously did not pay attention on this, but could it be related?
Caught it from gdb after a while. Not all debug symbols but it does point to mpegdemux plugin, so not the core you were right. 0x007b3724 in ?? () from /usr/lib/gstreamer-0.10/libgstmpegdemux.so Missing separate debuginfos, use: debuginfo-install glib2-2.28.8-1.fc15.i686 gstreamer-plugins-bad-free-0.10.22-1.fc15.i686 gstreamer-plugins-base-0.10.33-92.fc15.i686 gstreamer-plugins-good-0.10.29-1.fc15.i686 libxml2-2.7.8-6.fc15.i686 zlib-1.2.5-3.fc15.i686 (gdb) where
+ Trace 228012
Please also install debugging info for glib2 and for libgstmpegdemux/gst-plugins-bad. > (gst-launch-0.10:27336): GStreamer-WARNING **: Trying to set string on > structure field 'description', but string is not valid UTF-8. Please file a > bug. > > I previously did not pay attention on this, but could it be related? I don't think it's related. I've seen this before, might even have a partial fix somewhere, will have a look for it.
Took a bit longer to reproduce this time, here it is now: (gst-launch-0.10:27417): GStreamer-CRITICAL **: gst_buffer_create_sub: assertion `buffer->size >= offset + size' failed Program received signal SIGSEGV, Segmentation fault.
+ Trace 228021
Thread 3084753776 (LWP 27421)
It would be useful if you could save the stream on disk, and find a smallish sample of it that triggers the crash.
Via gst-launch, just replacing udpsink with filesink, or you were thinking about something on the lower level?
Also, I have only seen this crash when playing a stream using dvbbasebin, which is a stream coming directly from a local DVB-T tuner then. With other DVB-T MPEG TS sources which I can get over multicast (hardware appliances with DVB-T tuners which multicasts streams), or from a file, I have never seen this crash. I've seen other problems, like 655790 and 655804 specifically, other issues like no sound, various playback problems when playbin2 buffering flag is turned on, juddery playback, but never this one.
I was thinking exactly that, replacing udpsink with filesink. However, the mpeg demuxer is inside the dvb bin, so on second thoughts the crash would still be on your side, so nevermind :/
Created attachment 195080 [details] [review] Catch section lengths extending past the end of the buffer Likely fix. This is the only place I can see where something like this might happen. Looking at the logic, the section buffer seems to always be set when used, but one of the setup code bits might fail if corrupt data (or plain bad data) is fed through.
Created attachment 195082 [details] [review] Cttch section length extending past the buffer end Failed to submit, trying again.
I am running with this patch at the moment and will report back after some testing. (Sometimes it took quite a while to hit this.)
The patch is correct, and seems a likely candidate for the bug you reported. I fixed a similar problem while re-working the section handling code in the experimental 'tsdemux' element, but didn't think to check the older code.
I am hitting the new warning message and if that means previously it would crash then the fix is confirmed. But I will leave the test running for the day to increase the confidence.
Yes, this message triggers when the crash would have happened (_create_sub would detect this condition, and return NULL for the buffer, which would later be accessed).
commit 4275a70cb55d375afa702917f7359ec117ed49d4 Author: Vincent Penquerc'h <vincent.penquerch@collabora.co.uk> Date: Mon Aug 29 13:00:02 2011 +0100 mpegdemux: catch section lengths extending past the buffer length This is probably the cause for an occasional crash while streaming MPEG. Blind fix after staring at the code and following logic, so may or may not fix the issue, I cannot test.