GNOME Bugzilla – Bug 93735
Crash with gst-launch cdparanoia ! spider ! osssink
Last modified: 2004-12-22 21:47:04 UTC
This happens with a cvs from 19/09/2002 We found a workaround in monkey-media to get rid of that bug, but it would be better without ;) Here is a bt of the problem: ---------------------------- (gdb) run cdparanoia ! spider ! osssink Starting program: /home/olive/gnome/bin/gst-launch cdparanoia ! spider ! osssink [New Thread 1024 (LWP 13316)] INFO (13316: 0) Initializing GStreamer Core Library version 0.4.1.1 INFO (13316: 0) CPU features: (c1c7fbff) MMX 3DNOW MMXEXT registry: loaded user_registry in 0.000168 seconds (/home/olive/.gstreamer/registry.xml) registry: loaded global_registry in 0.103558 seconds (/home/olive/gnome//etc/gstreamer/registry.xml) GStreamer-INFO: 0 live buffer(s) GStreamer-INFO: 0 live bufferpool(s) GStreamer-INFO: 0 live event(s) RUNNING pipeline int2float adding pad src0 (process:13316): GLib-GObject-WARNING **: invalid uninstantiatable type `<invalid>' in cast to `GstScheduler' ERROR: sink_0: element "sink_0" is not decoupled but has pads in different schedulers Program received signal SIGSEGV, Segmentation fault.
+ Trace 27559
Thread 1024 (LWP 13316)
I'm seeing the same problem in some unreproducable cases where the backtrace gives a long circular list of gst_bin_change_state()... Maybe there's a bug in GstBin? Deleting and recreating the exact same pipeline fixes the problem, but you don't want that, of course. ;).
The problem is related to a state change failure. When a bin fails to change the state of one of its children, the children that succeeded the state change are reverted to their initial state, now if that fails, you have a loop... better check the plugins and fix them... or figure out what's wrong (could be capsnego too actually)
And as always, you were right. ;). Fixed for me... Olivier, can I close it or is this still bugged for you?
Nope, still bugged for me :( The backtrace changed though: bt: === RUNNING pipeline cdparanoia0: total-time = "3276" cdparanoia0: offsets = " 150 17968 40108 61960 86405 107018 144133 162300 178203 195538 215018 231828" cdparanoia0: discid = "a00cca0c" Program received signal SIGSEGV, Segmentation fault.
+ Trace 27856
Thread 1024 (LWP 6337)
As Wim suggested, the problem was a state change failure. The point for me was to find out which element caused the state change failure (just browse through the --gst-mask=-1 output and grab a cop of coffee, probably two or more ;-) ), and fix the cause of why the state_change failed. In my case, it was an uninitialised variable (filesink->location wasn't set). Hope this helps a bit... I was getting the weirdest unusable backtraces, so they weren't really helpful. --gst-mask=-1 (or --gst-mask=0x0100040, that just gives state change and capsnego output). If that doesn't help, add some debug info to the state_change fuctions of the plugins you're using and see which one fails... It's quite some work, I know, but it worked for me.
Still able to reproduce with cvs from 26/10/2002 14:00 MonkeyMedia doesn't use spider anymore so this bug is not a problem anymore for Rhythmbox...
Fixed in HEAD
Applied (partly) to 0.6.1 too.