[Bug 685555] collectpads unit test fails

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Thu Mar 7 05:20:16 PST 2013


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

--- Comment #3 from Jonas Holmberg <jonas.holmberg at axis.com> 2013-03-07 13:20:13 UTC ---
There were three threads in the test cases that hanged: the test thread and two
threads that push buffers. Each thread push one buffer on one pad. There are
two pads in the collectpads so the second buffer will trigger the
collect-callback. 

This is what happens when the hang occurs:

The first thread pushes a buffer and initializes a cookie to the value of a
counter in the collectpads object and waits on a cond for the counter to change
and for someone to consume the buffer (i.e. _pop() it).

The second thread pushes a buffer and calls the collected callback, which
signals the cond that the test thread is waiting for.

The test thread pops both buffers (without holding any lock). Each call to
_pop() increases the counter broadcasts the condition that the first thread is
now waiting for. It then joins both threads (hangs).

The first thread wakes up and returns, since its buffer has been consumed.

The second thread starts executing again. When the callback, called by the
second thread, has returned it initializes a cookie to the value of a counter,
which has already prematurely been increased by the test thread when it popped
the buffers, and wait's on a cond for the counter to change and for someone to
consume the buffer (i.e. _pop() it). Since the buffer has already been poped
and the counter has already been increased it will be stuck forever.

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


More information about the gstreamer-bugs mailing list