From: GStreamer (bugzilla.gnome.o. <bug...@gn...> - 2011-02-09 14:31:01
|
https://bugzilla.gnome.org/show_bug.cgi?id=641928 GStreamer | gstreamer (core) | git Wim Taymans <wim.taymans> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wim...@gm... --- Comment #1 from Wim Taymans <wim...@gm...> 2011-02-09 14:30:48 UTC --- > > You can see that there is a (very rare) possible race such that during the line > marked with the comment, the whole pad deactivation phase could be executed > (including the lock/unlock cycle). The effect is that the chain function gets > still called afterwards, which will obviously lead to random crashes. You are right. <snip> > > I suppose an easy fix would be to take the stream lock earlier (before > acquiring the cache), and release it when falling back to slow path (an extra > unlock/lock pair, which probably could be avoided with some more refactoring > later). That would not work because we need to take the stream_lock of the peer pad, which we can only get after getting the cache. Also the flushing flag is on the peer pad and with the object lock. It seems that there is no other way than checking the flushing flag after getting the stream lock.. That would add one more object lock/unlock because the flags are currently not atomic. -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |