GNOME Bugzilla – Bug 631768
mini object refcount issue and crash in complex pipeline
Last modified: 2011-04-15 13:42:20 UTC
Caught SIGSEGV accessing address 0xad1fe9af
+ Trace 224074
Showing gdb with debuginfo loaded doesn't show more in the backtrace. It does show: Cannot access memory at address 0x44c70808 process started with "sh cam01-launch" where cam01-launch contains: gst-launch gstrtpbin name=rtpbin rtspsrc location=rtsp://192.168.1.70:7070 ! tee name=t t. ! queue ! rtpbin.send_rtp_sink_0 rtpbin.send_rtp_src_0 ! udpsink host=192.168.1.1 port=37886 rtpbin.send_rtcp_src_0 ! udpsink host=192.168.1.1 port=37887 sync=false async=false t. ! queue ! decodebin ! videorate ! video/x-raw-yuv,framerate=1/60 ! ffmpegcolorspace ! pngenc snapshot=false ! multifilesink location="/home/dave/cam01.png" t. ! queue ! rtpmp4vdepay ! filesink location=/home/dave/cam01.mp4 The process (in this case) ran for about 14 hours and 40 minutes before the segfault. The process did not terminate, but the stream stopped recording to the disk, the snapshots stopped, but the stream from the camera continued until the process was killed. This has happened several times with the amount of time that the process runs varying from about 40 minutes up to the 14 hours+. I'll start it again with gst-debug-level set to 3 and send the output later.
Please run gdb like this: $ gdb --args /usr/bin/gst-launch-0.10 gstrtpbin name=... This should result in a better stack trace.
Created attachment 172103 [details] gdb backtrace
The attached backtrace (after an additional 57 debug infos requested by gdb) is a bit better.
So you've got a refcounting issue somewhere. Maybe you could run this again with G_DEBUG=fatal_warnings to see where in the pipeline the mini object warning comes from, and if it's a buffer or event. It's pretty hard to debug this kind of thing remotely without a reproducible test at hand. I would suggest you try to simplify your pipeline a bit more. Alternatively, maybe it's possible to capture the input stream so you can replay it locally. Also make sure to use the latest versions of everything, maybe the problem has already been fixed.
The refcounting messages occur within the first few seconds of operation, the segfault occurs hours into the process. I went ahead and ran the process with gst-debug-level=3, which produced a 500+MB file. I trimmed it to within a few hundred messages after the segfault and bzipped it down to 6.5MB. Will bugzilla accept that large an attachment? There are a huge number of: ffmpeg :0:: marker does not match f_code error messages with the occassional ffmpeg :0:: concealing 13 DC, 13 AC, 13 MV errors where the number of concealed errors varies. I'm guessing that the output that I'm recording is modified by this, and won't reflect actual input.
Does this still happen with the latest releases? (core/base 0.10.32, good 0.10.27, ugly 0.10.17, bad 0.10.21, gst-ffmpeg 0.10.11)? > The refcounting messages occur within the first few seconds of operation, the > segfault occurs hours into the process. I went ahead and ran the process with > gst-debug-level=3, which produced a 500+MB file. I trimmed it to within a few > hundred messages after the segfault and bzipped it down to 6.5MB. Will > bugzilla accept that large an attachment? bugzilla only accepts attachments up to 1MB. Also, even if it would accept full logs, it's unlikely that someone would be able to figure out the problems looking at them. I would suggest you try to simplify the pipeline to the bare minimum (the important thing is the refcount warning, after that anything can happen), or try to come up with a pipeline that makes it easy for us to reproduce the issue (e.g. using public streams or videotestsrc or somesuch).
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!