GNOME Bugzilla – Bug 582169
[multipartdemux] Segmentation fault on empty content
Last modified: 2009-05-21 20:07:52 UTC
multipartdemux causes a segmentation fault when the content is empty. Trigger with gst-launch fakesrc ! image/jpeg ! multipartmux ! multipartdemux ! fakesink The cause is that it tries to take a zero-sized buffer from the adapter. I'll provide a patch that skips empty content parts. Perhaps an empty buffer should be pushed instead, but that doesn't seem very convenient.
Created attachment 134393 [details] [review] multipartdemux: allow content to be empty
Created attachment 134394 [details] [review] Test that fails on git HEAD An addition to the simple-launch-lines test that creates the following launch line gst-launch fakesrc num-buffers=20 sizetype=3 sizemin=0 sizemax=2 ! image/jpeg ! multipartmux ! multipartdemux ! fakesink sizetype=3 is added to make sure there are some non-empty buffers. Otherwise, it never prerolls because no buffers make it through the multipartdemux.
*** Bug 582731 has been marked as a duplicate of this bug. ***
but still the problem persist
> but still the problem persist Yes, that is why the bug is still open. When the issue gets fixed, the bug status will be changed to RESOLVED|FIXED.
It is extremely unlikely that you get the same output after applying attachment (id=134393) because it puts the gst_adapter_take_buffer(datalen) is the else-branch of "if (datalen <= 0)"... If the problem really persists after you have applied the patch to gst-plugins-good and you have verified that you are using the freshly compiled libgstmultipart.so and not an old version, then can you do the following in gdb at the point where you get the SEGV? print datalen print size print outbuf print srcpad print created
I took the latest version from git repository and installed.I think the patch is added to this .
No, it's not yet reviewed or commited to git. If it was, the patch would be labeled 'commited'. Your original report was set to resolved because it's a duplicate, not because it's fixed in git. It would be good if you could test if this patch makes things work for you.
the patch looks ok but we have to wait after the freeze before we can commit this.
make producing the following errors multipartdemux.c: In function 'gst_multipart_demux_chain': multipartdemux.c:572: error: invalid storage class for function 'gst_multipart_demux_change_state' cc1: warnings being treated as errors multipartdemux.c:569: error: ISO C90 forbids mixed declarations and code multipartdemux.c:606: error: invalid storage class for function 'gst_multipart_set_property' multipartdemux.c:633: error: invalid storage class for function 'gst_multipart_get_property' multipartdemux.c:662: error: expected declaration or statement at end of input make[3]: *** [libgstmultipart_la-multipartdemux.lo] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2
You have misapplied the patch. The patched multipartdemux from git HEAD contains only 644 lines...
i added that patch successfully .But still for the mjpeg capturing, i am getting the following errors. gst-launch -v gnomevfssrc do-timestamp=TRUE location="http://carinov:carinov123@10.0.0.150:8000/nphVideo?Mode=0&Resolution=320x240&Quality=Standard" ! decodebin ! xvimagesink Setting pipeline to PAUSED ... Pipeline is PREROLLING ... /GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind.GstPad:src: caps = multipart/x-mixed-replace /GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstMultipartDemux:multipartdemux0.GstPad:sink: caps = multipart/x-mixed-replace ERROR: from element /GstPipeline:pipeline0/GstGnomeVFSSrc:gnomevfssrc0: Internal data flow error. Additional debug info: gstbasesrc.c(2336): gst_base_src_loop (): /GstPipeline:pipeline0/GstGnomeVFSSrc:gnomevfssrc0: streaming task paused, reason not-linked (-1) ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... /GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstMultipartDemux:multipartdemux0.GstPad:src_0: caps = NULL /GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstMultipartDemux:multipartdemux0.GstPad:sink: caps = NULL /GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind.GstPad:src: caps = NULL Freeing pipeline ... gdb log -------------------- (gdb) run Starting program: /usr/local/bin/gst-launch-0.10 gnomevfssrc do-timestamp=TRUE location=http://carinov:carinov123@10.0.0.150:8000/nphVideo\?Mode=0\&Resolution=320x240\&Quality=Standard \! decodebin \! xvimagesink [Thread debugging using libthread_db enabled] [New Thread 0xb7ee5710 (LWP 22775)] Detaching after fork from child process 22778. Setting pipeline to PAUSED ... [New Thread 0xb7ce3b90 (LWP 22779)] [New Thread 0xb72e2b90 (LWP 22780)] Pipeline is PREROLLING ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock ERROR: from element /GstPipeline:pipeline0/GstGnomeVFSSrc:gnomevfssrc0: Internal data flow error. Additional debug info: gstbasesrc.c(2336): gst_base_src_loop (): /GstPipeline:pipeline0/GstGnomeVFSSrc:gnomevfssrc0: streaming task paused, reason not-linked (-1) Execution ended after 567312 ns. Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... [Thread 0xb7ce3b90 (LWP 22779) exited] Freeing pipeline ... Program exited normally. just blinked the video and disappeared!
ya..It contained 644 lines.The video is just blinked and disappeared.
multipartdemux does not properly handle stream flow agregation. Will make a patch later.
Created attachment 135012 [details] [review] do combine flows and fix mime-types This patch should be applied after attachement 134393. - Add correct flow combine when dealing with multiple streams - add audio/g726 mime type mapping - Fix other g726 mime types - Make mime-types case insensitive
With the above patch, this should sortof work: /usr/local/bin/gst-launch-0.10 gnomevfssrc do-timestamp=TRUE location=http://carinov:carinov123@10.0.0.150:8000/nphVideo\?Mode=0\&Resolution=320x240\&Quality=Standard ! multipartdemux name=d ! queue ! jpegdec ! xvimagesink d. ! queue ! ffdec_g726 ! audioconvert ! audioresample ! alsasink If it doesn't work, add sync=false to all sinks.
/usr/local/bin/gst-launch-0.10 gnomevfssrc do-timestamp=TRUE location=http://carinov:carinov123@10.0.0.150:8000/nphVideo\?Mode=0\&Resolution=320x240\&Quality=Standard ! multipartdemux name=d ! queue ! jpegdec ! xvimagesink sync=false d. ! queue !ffdec_g726 ! audioconvert ! audioresample ! alsasink sync=false getting, could not link alsasink0 to audioconvert gst-launch-0.10 -v gnomevfssrc do-timestamp=TRUE location=http://carinov:carinov123@10.0.0.150:8000/nphVideo\?Mode=0\&Resolution=320x240\&Quality=Standard ! multipartdemux name=d ! queue ! jpegdec ! xvimagesink sync=false d. ! queue ffdec_g726 ! audioconvert ! audioresample ! alsasink produced the output Setting pipeline to PAUSED ... Pipeline is PREROLLING ... /GstPipeline:pipeline0/GstQueue:queue0.GstPad:sink: caps = image/jpeg /GstPipeline:pipeline0/GstQueue:queue0.GstPad:src: caps = image/jpeg /GstPipeline:pipeline0/GstJpegDec:jpegdec0.GstPad:sink: caps = image/jpeg /GstPipeline:pipeline0/GstJpegDec:jpegdec0.GstPad:src: caps = video/x-raw-yuv, format=(fourcc)I420, width=(int)320, height=(int)240, framerate=(fraction)0/1 /GstPipeline:pipeline0/GstQueue:queue1.GstPad:sink: caps = audio/x-adpcm, bitrate=(int)32000, layout=(string)g726, channels=(int)1, rate=(int)8000 /GstPipeline:pipeline0/GstXvImageSink:xvimagesink0.GstPad:sink: caps = video/x-raw-yuv, format=(fourcc)I420, width=(int)320, height=(int)240, framerate=(fraction)0/1
still getting a single image in the recorded output.