GNOME Bugzilla – Bug 643772
[playsink] Sometimes uses already freed objects leading to crashes
Last modified: 2011-03-07 20:49:26 UTC
Hi, I'm reproducing that crash quite easily, after having play 2/3 video files : Program received signal SIGSEGV, Segmentation fault.
+ Trace 226180
Thread 140736718681856 (LWP 29344)
Here my packages versions on Debian (quite close from upstream) : ii gstreamer0.10-ffmpeg 0.10.11-4 FFmpeg plugin for GStreamer ii gstreamer0.10-plugins-bad 0.10.21-1 GStreamer plugins from the "bad" set ii gstreamer0.10-plugins-base 0.10.32-1 GStreamer plugins from the "base" set ii gstreamer0.10-plugins-good 0.10.27-1 GStreamer plugins from the "good" set ii gstreamer0.10-plugins-ugly 0.10.17-1 GStreamer plugins from the "ugly" set ii libgstreamer0.10-0 0.10.32-4 Core GStreamer libraries and elements ii libgstreamer-plugins-base0.10-0 0.10.32-1 GStreamer libraries from the "base" set
Does this happen for specific video files, special codecs or anything? Could you get a valgrind log of this crash (don't forget to set the G_SLICE environment variable G_SLICE=malloc).
And use --track-origins=yes when using valgrind.
I'm using some demotivational videos from koreus.com, mostly .mp4 contained streams : $ file ~/Videos/*.mp4 ~/Videos/caniches-betise.mp4: ISO Media, MPEG v4 system, version 2 ~/Videos/chat-laser-bowling.mp4: ISO Media, MPEG v4 system, version 2 ~/Videos/descente-vtt-valparaiso.mp4: ISO Media, MPEG v4 system, version 2 ~/Videos/farm-wars.mp4: ISO Media, MPEG v4 system, version 2
Actually running valgrind on my application slows it so bad, that I can't get to the point were I reproduce the problem...
After ~2h running the application, some more evidences: ==22905== Thread 9: ==22905== Invalid read of size 8 ==22905== at 0x9945A47: g_object_set (gobject.c:1796) ==22905== by 0x16D7E564: update_av_offset (gstplaysink.c:2705) ==22905== by 0x16D82C78: gst_play_sink_reconfigure (gstplaysink.c:2572) ==22905== by 0x16D77B80: no_more_pads_cb (gstplaybin2.c:2767) ==22905== by 0x993EDFD: g_closure_invoke (gclosure.c:766) ==22905== by 0x99571A6: signal_emit_unlocked_R (gsignal.c:3252) ==22905== by 0x9958825: g_signal_emit_valist (gsignal.c:2983) ==22905== by 0x9958D72: g_signal_emit (gsignal.c:3040) ==22905== by 0x993EDFD: g_closure_invoke (gclosure.c:766) ==22905== by 0x99571A6: signal_emit_unlocked_R (gsignal.c:3252) ==22905== by 0x9958825: g_signal_emit_valist (gsignal.c:2983) ==22905== by 0x9958D72: g_signal_emit (gsignal.c:3040) ==22905== Address 0x159e1a80 is 0 bytes inside a block of size 1,328 free'd ==22905== at 0x4C240FD: free (vg_replace_malloc.c:366) ==22905== by 0x9962AFB: g_type_free_instance (gtype.c:1932) ==22905== by 0x598D3AB: gst_message_finalize (gstmessage.c:196) ==22905== by 0x598DA70: gst_mini_object_unref (gstminiobject.c:338) ==22905== by 0x596DA37: gst_bus_set_flushing (gstmessage.h:323) ==22905== by 0x599BBAC: gst_pipeline_change_state (gstpipeline.c:518) ==22905== by 0x16D7B671: gst_play_bin_change_state (gstplaybin2.c:3542) ==22905== by 0x597926B: gst_element_change_state (gstelement.c:2651) ==22905== by 0x59792EE: gst_element_change_state (gstelement.c:2688) ==22905== by 0x597C2FA: gst_element_set_state_func (gstelement.c:2607) ==22905== by 0x52EED99: clutter_gst_video_texture_set_property (clutter-gst-video-texture.c:383) ==22905== by 0x9945401: g_object_set_valist (gobject.c:1178) ==22905== ==22905== Invalid read of size 8 ==22905== at 0x995BF87: g_type_check_instance_is_a (gtype.c:3936) ==22905== by 0x9945A61: g_object_set (gobject.c:1796) ==22905== by 0x16D7E564: update_av_offset (gstplaysink.c:2705) ==22905== by 0x16D82C78: gst_play_sink_reconfigure (gstplaysink.c:2572) ==22905== by 0x16D77B80: no_more_pads_cb (gstplaybin2.c:2767) ==22905== by 0x993EDFD: g_closure_invoke (gclosure.c:766) ==22905== by 0x99571A6: signal_emit_unlocked_R (gsignal.c:3252) ==22905== by 0x9958825: g_signal_emit_valist (gsignal.c:2983) ==22905== by 0x9958D72: g_signal_emit (gsignal.c:3040) ==22905== by 0x993EDFD: g_closure_invoke (gclosure.c:766) ==22905== by 0x99571A6: signal_emit_unlocked_R (gsignal.c:3252) ==22905== by 0x9958825: g_signal_emit_valist (gsignal.c:2983) ==22905== Address 0x159e1a80 is 0 bytes inside a block of size 1,328 free'd ==22905== at 0x4C240FD: free (vg_replace_malloc.c:366) ==22905== by 0x9962AFB: g_type_free_instance (gtype.c:1932) ==22905== by 0x598D3AB: gst_message_finalize (gstmessage.c:196) ==22905== by 0x598DA70: gst_mini_object_unref (gstminiobject.c:338) ==22905== by 0x596DA37: gst_bus_set_flushing (gstmessage.h:323) ==22905== by 0x599BBAC: gst_pipeline_change_state (gstpipeline.c:518) ==22905== by 0x16D7B671: gst_play_bin_change_state (gstplaybin2.c:3542) ==22905== by 0x597926B: gst_element_change_state (gstelement.c:2651) ==22905== by 0x59792EE: gst_element_change_state (gstelement.c:2688) ==22905== by 0x597C2FA: gst_element_set_state_func (gstelement.c:2607) ==22905== by 0x52EED99: clutter_gst_video_texture_set_property (clutter-gst-video-texture.c:383) ==22905== by 0x9945401: g_object_set_valist (gobject.c:1178) ==22905==
Ok, thanks. That's quite useful
So for some reason the ts_offset elements for the audio and video chain are not valid anymore and their last reference was dropped by some message. Are you using any special sinks for audio and/or video here?
We construct the pipeline with playbin2 and use the ClutterGstVideoSink (http://git.clutter-project.org/clutter-gst) and no particular audio sink.
Thanks, and this does happen when playing the first file and not only when switching from one file to another, right?
Indeed that happens when we switch from one video to another. We have a background video in our UI (kind of animated background) and when we play a video, we stop the background video and switch to media we want to play. I'm pretty sure we use 2 different ClutterGstVideoSink, but I need to check.
Actually we use the same pipeline, and when switching from one video to another we just : 1. save the current state of the pipeline 2. set the pipeline state to NULL 3. change the uri 4. set back the pipeline to the saved state all of this in the same function.
Unfortunately I'm unable to reproduce it here (do you have a small sample application for reproducing it?) but I guess the problem will be quite obvious when looking closer at the code.
Oh this is likely fixed by the fix for bug #642466: commit 19052a847d43c489e6bfd249d4e63ba31e630fe1 Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk> Date: Wed Feb 23 14:31:13 2011 +0100 playsink: release all chains when going to NULL Also fixes #642466. Can you confirm this?
A piece of code is worth a description : http://git.clutter-project.org/clutter-gst/tree/clutter-gst/clutter-gst-video-texture.c#n331
Sounds like my problem :) I confirm that the test case of #642466 leads to increasing the ref each time the state changes. Give me some time rebuild the gstreamer package.
Ok, I recompiled the whole Gst stack with the last git versions and the problem is fixed. Thank you very much ! *** This bug has been marked as a duplicate of bug 642466 ***
(In reply to comment #11) > Actually we use the same pipeline, and when switching from one video to another > we just : > 1. save the current state of the pipeline > 2. set the pipeline state to NULL > 3. change the uri > 4. set back the pipeline to the saved state > > all of this in the same function. FYI, GST_STATE_READY is sufficient to change the uri and would result in a quicker change over.
Is that true when the file is different ? Switch from a divx file to an mkv ?
(In reply to comment #18) > Is that true when the file is different ? Switch from a divx file to an mkv ? Yes