[Bug 732556] pad: Race condition when removing sticky events

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=732556
  GStreamer | gstreamer (core) | unspecified

--- Comment #3 from Göran Jönsson <goran.jonsson at axis.com> 2014-07-02 05:57:28 UTC ---
I do not have a complete explanation on what happens, but i have more
information.

We have set up a test that we are running several hundred times before this
happens. First I try explain test case.

Testcase: This is a RTSP session where the rtp packets are in tcp packets, and
we are using something we call pullmode. This mean that we try to stream all
data as fast as possible not in the speed that it should be shown for end user.
We 
have a test client that are not reading any data at all in beginning and the
first period of not reading at all it is followed by a period of reading slow.
This is followed by a short period were clients read as fast as possible then
client is doing pause and then teardown. This causes queues and stuff to be
pretty loaded by data when the session is teardown.

What I have seen in the remove_events func several times  is that before loop.
( I have a func that prints all events in list) there is 5 events. 

When entering the loop the first event is handled as it should and second is a
GST_EVENT_CAPS and after the unlock notify lock sequence strange things
happends. Now it proccess the 4:th event and then the 5:th and after that
another event that is same as the 5:th and here we got the double unref.

My interpretation of this is that during unlock notify lock sequence there is
someone manipulating the list probable remove event 3 and change size of list.
So the last iteration is done on data outside the actual list size causing the
doubble unref of the last event. 

With the code change the problem disappear.

If I had access to trace tools like Lauterbach or similar I could analyze this
in more detail but I don't have access to tools like that. I have tried to use
my function that prints the list of events inside loop but then it just crash.

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