GNOME Bugzilla – Bug 420106
[basetransform] race on shutdown: setcaps func called after pad set flushing
Last modified: 2007-07-25 14:42:04 UTC
The bug has been opened on https://launchpad.net/bugs/93282 "Binary package hint: totem Well, I was trying to read a movie with totem, I already opened it successfully with Totem (avi + subtitles). But this time, Totem couldn't start properly and was closing just after the start and a "could not initialize" message. I started Totem again and again and it crashed. I cannot reproduce it as totem is now working fine again. ProblemType: Crash Architecture: i386 Date: Sun Mar 18 04:22:14 2007 DistroRelease: Ubuntu 7.04 ExecutablePath: /usr/bin/totem Package: totem-gstreamer 2.18.0-0ubuntu1 PackageArchitecture: i386 ProcCmdline: totem file:///home/pthivent/My%20Videos/lost.312.hdtv-caph.avi ... .
+ Trace 120023
Thread 11 (process 20695)
Thread 10 (process 20697)
Thread 9 (process 20698)
Thread 8 (process 20699)
Thread 7 (process 20700)
Thread 6 (process 20701)
Thread 5 (process 20702)
Thread 4 (process 20703)
Thread 3 (process 20705)
Thread 2 (process 20706)
Thread 1 (process 20704)
http://librarian.launchpad.net/6995855/%3Cfdopen%3E has a similar backtrace coming from rhythmbox.
> http://librarian.launchpad.net/6995855/%3Cfdopen%3E has a similar backtrace > coming from rhythmbox. Very useful, thanks! So, I wonder if the following race(?) could happen when a GstBaseTransform-based element's state goes from PAUSED => READY: Streaming-Thread: in gst_pad_chain_unchecked(): - take STREAM_LOCK - take OBJECT_LOCK - check if pad is flushing - release OBJECT_LOCK Shutdown-Thread: in gst_pad_activate_push(FALSE): - take OBJECT_LOCK (in pre_activate) - set pad to flushing (in pre_activate) - release OBJECT_LOCK (in pre_activate) - call GST_PAD_ACTIVATEPUSHFUNC(), which was set by GstBaseTransform and which will call GstBaseTransform::stop() where elements might clear all their state. Streaming-Thread: still in gst_pad_chain_unchecked(): - call gst_pad_configure_sink() which will/might cause GstBaseTransform::set_caps() to be called, which elements will only expect after they have been started again and their state has been initialised Or am I missing anything here? If not, core bug, basetransform bug or element bug?
another totem crash on https://launchpad.net/bugs/99388, the description: "Totem crashes when you select more than one file in nautilus and press enter. The default user want's to make a playlist in this way and it would be nice if you can fix it. ..." Do you need some GST_DEBUG log?
Core bug, me thinks. Bug #412870 might also be related.
basetransform should not call stop before the STREAM_LOCK has been acquired.
Created attachment 86740 [details] [review] Make sure streaming has finished before calling GstBaseTransform::stop() which might clear state
Fixed in core: 2007-04-21 Tim-Philipp Müller <tim at centricular dot net> * libs/gst/base/gstbasetransform.c: (gst_base_transform_activate): Make sure streaming has stopped before calling the ::stop() vfunc, since that vfunc might clear state which is being used in the streaming thread. This fixes a race that caused crashes in audioresample when shutting down a pipeline (#420106). Also committed unit test to gst-plugins-base: 2007-04-21 Tim-Philipp Müller <tim at centricular dot net> * tests/check/elements/audioresample.c: Add unit test for audioresample shutdown crasher (#420106).
*** Bug 430522 has been marked as a duplicate of this bug. ***
*** Bug 419808 has been marked as a duplicate of this bug. ***
*** Bug 412851 has been marked as a duplicate of this bug. ***
*** Bug 432358 has been marked as a duplicate of this bug. ***
*** Bug 450620 has been marked as a duplicate of this bug. ***
*** Bug 459043 has been marked as a duplicate of this bug. ***