[Bug 692691] Dangling pointer when doing allocation query on a flushing queue

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=692691
  GStreamer | gstreamer (core) | 1.x

--- Comment #5 from Alexander Schrab <alexas at axis.com> 2013-01-29 11:28:08 UTC ---
I finally have a unit test that triggers the bug *sometimes*, I wanted but have
so far failed in making it fail all the time. I narrowed the problem down to
this:

Making allocation queries to the queue while simultaneously sending one
flush_start to the queue can trigger this. The reason being as I said earlier: 

handle_sink_query falls out through out_flushing: while waiting for the query
to complete. This results in a race between the thread doing a query that will
most likely unref the query when the function returns and the queue that will
try to flush out the query (doing an GST_IS_QUERY(data) on something that might
already be deleted).

So what can be done?

1. as we said before, we can either ref or make sure the item is gone (I do
prefer the ref since we can remove a number of special cases for the query data
items)
2. Make sure we always call gst_queue_locked_flush right after setting
srcresult to GST_FLOW_FLUSHING, before we let the query call return (it is
waiting for GST_QUEUE_WAIT_DEL_CHECK (queue, out_flushing)). This behavior is
already there when pushing buffers results in setting srcresult to flushing as
far as I can see, but I have way to little knowledge of the queue to understand
if the gst_queue_locked_flush can be used that way.


I'm adding the test case if someone wants to take a look... It's a pretty ugly
unit test with sleep etc, so it's not in a state to import...

-- 
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.