GNOME Bugzilla – Bug 506301
Crash after changing the audiosink of a playbin
Last modified: 2012-10-03 23:05:37 UTC
Please describe the problem: After changing the audio-sink of a PlayBin element, some messages coming from the bus can cause random crash when querying its type. I guess it's because this message comes from the old audio-sink that doesn't exist anymore. By the way, being able to know the source object of the message (included in the GstMessage structure) would be nice. I'm not sure it's a binding bug. Steps to reproduce: run the attached program with an audio file as argument Actual results: random crashes, after a random number of play/stop (1 to ~20) Expected results: Does this happen every time? Other information: versions used : perl-Glib-1.160-1mdv2008.0 perl-Gtk2-1.160-1mdv2008.0 perl-GStreamer-0.09-1mdv2007.0 libgstreamer0.10_0.10-0.10.14-1mdv2008.0 libglib2.0_0-2.14.1-2mdv2008.0
Created attachment 101800 [details] test case run with an audio file as argument, it crashes rapidly. Commenting the line with $msg->type OR not making it a string OR not changing the audio-sink make the crash disappear.
I'm not seeing this bug with libgstreamer 0.10.14 on Ubuntu (at least there's no crash until "-----play 532" after which I stopped the program). I tried an MP3 and an OGG file. Can you install debug packages and then try to get a backtrace and/or valgrind output? $ gdb perl # r bug_changesink.pl <path> <Segfault> # bt <Backtrace> $ valgrind --tool=memcheck --num-callers=100 perl bug_changesink.pl <path> > By the way, being able to know the source object of the message (included in > the GstMessage structure) would be nice. That's true. Added in HEAD of CVS.
Sorry for not replying sooner. In the meantime I upgraded to mandriva 2008.1, with : perl-Glib-1.180-1mdv2008.1 perl-GStreamer-0.09-2mdv2008.1 libgstreamer0.10_0.10-0.10.17-3mdv2008.1 libglib2.0_0-2.16.2-1mdv2008.1 and I've also tested it with manually compiled versions of the latest gstreamer library and plugins and perl bindings GStreamer-0.11 gstreamer-0.10.19 gst-plugins-base-0.10.19 gst-plugins-ugly-0.10.8 gst-plugins-bad-0.10.7 It seems somethings have changed, or maybe I made some mistakes earlier. With mp3 or ogg, it usually runs fine, but in some rare cases, crashes early. With flac or mpc, it crashes reliably before the ~30th iteration. Also it still crashes if I comment the line with $msg->type, the only way it doesn't crash is by not changing the sink everytime or by not connecting to the "message" signal (even an empty callback causes crashes). The crashes are totally random, sometimes preceded by bogus error messages. Usually ending with a "Segmentation fault", but also "*** glibc detected *** perl: double free or corruption (fasttop): 0x083f2c78" or "Out of memory!" ... The backtrace are different each time. I can't reproduce the crash when running under valgrind, the output doesn't seem to contain anything useful, but I'll attach it. I'm beginning to think it's a gstreamer bug and not a bug in the bindings.
Created attachment 111355 [details] valgrind output Output of valgrind, made with valgrind --tool=memcheck --num-callers=100 perl bug_changesink.pl file.flac
Sorry, I'm still unable to reproduce this. With 1.flac from http://ff123.net/samples.html, your test case ran fine here. I stopped it after "play 313".
Quentin, you haven't provided the stacktrace you've been asked for in comment #2, yet. Thus I'm closing for now. If you have any news, don't hesitate to reopen!
Sorry I didn't reply, I wanted to do more tests, but I forgot. I don't think the backtraces will help, because when it crashes, it is at random places. Anyway, I discovered that the errors only happened when the file was specified with an absolute path, not a relative path. The crashes are very random, but I managed to reproduced the error messages below on ubuntu 8.10, fedora 10 and mandriva 2009.0 with the example file from ubuntu that can be downloaded at : http://launchpadlibrarian.net/18785858/patas_de_trapo.oga With this file, specified with an absolute path, I reliably get these errors : ----play 35 -----stop 35 GLib-GObject-WARNING **: invalid unclassed pointer in cast to `GObject' at bug_changesink.pl line 29. GLib-GObject-CRITICAL **: g_object_set: assertion `G_IS_OBJECT (object)' failed at bug_changesink.pl line 29. -----play 36 -----stop 36 GLib-GObject-WARNING **: invalid uninstantiatable type `<invalid>' in cast to `GObject' at bug_changesink.pl line 29. GLib-GObject-CRITICAL **: g_object_set: assertion `G_IS_OBJECT (object)' failed at bug_changesink.pl line 29. -----play 37 -----stop 37 Also, there is a big memory usage difference, when run with relative path, the virtual memory usage, as seen by top, is around 35m, it is around 70m when run with an absolute path. Note that, even with the relative path, the memory usage rise, slowly, but consistently, so there is probably a leak even with a relative path. When run with valgrind, I get very different numbers depending on if I use an absolute or a relative path (both stopped with a ctrl-c after ~50 iterations) : *** with relative path (no error messages) : ==12564== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 269 from 1) ==12564== malloc/free: in use at exit: 4,738,924 bytes in 51,063 blocks. ==12564== malloc/free: 113,871 allocs, 62,808 frees, 7,779,096 bytes allocated. ==12564== For counts of detected errors, rerun with: -v ==12564== searching for pointers to 51,063 not-freed blocks. ==12564== checked 4,560,968 bytes. ==12564== ==12564== LEAK SUMMARY: ==12564== definitely lost: 4,223 bytes in 77 blocks. ==12564== possibly lost: 202,069 bytes in 173 blocks. ==12564== still reachable: 4,532,632 bytes in 50,813 blocks. ==12564== suppressed: 0 bytes in 0 blocks. *** with absolute path (and error messages) : 2477== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 245 from 1) ==12477== malloc/free: in use at exit: 5,406,094 bytes in 57,093 blocks. ==12477== malloc/free: 287,703 allocs, 230,610 frees, 44,634,021 bytes allocated. ==12477== For counts of detected errors, rerun with: -v ==12477== searching for pointers to 57,093 not-freed blocks. ==12477== checked 31,032,484 bytes. ==12477== ==12477== LEAK SUMMARY: ==12477== definitely lost: 4,223 bytes in 77 blocks. ==12477== possibly lost: 336,917 bytes in 1,190 blocks. ==12477== still reachable: 5,064,954 bytes in 55,826 blocks. ==12477== suppressed: 0 bytes in 0 blocks.
Sorry, ignore the part about using a relative path, it just results in not finding the file without displaying any warning. This is what happen when you over-simplify the test script :( So run the test script with the full path of the file http://launchpadlibrarian.net/18785858/patas_de_trapo.oga it should at least print the error messages (not for every iterations), and maybe crash.
Hm. I'm not sure about that Stacktrace thing. I'd say that it might be of any use, even if you don't see it. You might want to have a look at http://library.gnome.org/devel/glib/unstable/glib-running.html. Also, I suggest to export G_DEBUG=fatal_warnings before launching gdb. Also, G_SLICE=debug-blocks might be of interest. Good Luck :)
Created attachment 127225 [details] gdb output with fatal warnings I didn't think of using G_DEBUG=fatal_warnings, here's the backtrace made with G_SLICE=debug-blocks and G_DEBUG=fatal_warnings and the glib/gstreamer dbg packages installed. But anyway, I could reproduce the errors on live-cd virtualbox sessions of fedora 10 and ubuntu 8.10. So you should have no problem in reproducing it. Just make sure you run the test script with the full path to the audio file.
OK, I can reproduce now. This appears to be a timing-related threading issue inside the playbin element. I attach Quentin's Perl test case, stripped down to the minimum, and an equivalent C program showing the same behavior. Leaving STOP_TIMEOUT set to 100 causes the errors to appear, changing it to, say, 500 makes them go away. The backtrace in comment 10 contains the relevant information. Running either program under valgrind doesn't produce useful information because valgrind's overhead prevents the errors from occurring.
Created attachment 131551 [details] Perl test case, stripped down
Created attachment 131552 [details] Equivalent C test case
Hrm, this is quite an old bug. In any case, can't reproduce this with 1.0.