GNOME Bugzilla – Bug 685555
collectpads unit test fails
Last modified: 2013-03-18 10:53:19 UTC
Doing make libs/collectpads.forever hangs after a while. From a quick look at the code it looks like collectpads has some races that cause it to lock up. The evt_cookie, for example, can be incremented before the other thread picks up the value and goes into an infinite wait.
libs/collectpads.c:94:E:general:test_collect:0: (after this point) Test timeout expired
Created attachment 238278 [details] [review] Call _pop() from collected callback to avoid races
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.
commit afbba8974ae54c591edd725842422fe5d51a0350 Author: Jonas Holmberg <jonashg@axis.com> Date: Thu Mar 7 12:11:30 2013 +0100 tests: fix spurious failure in test_collect collectpads test pop() in collected callback. 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. https://bugzilla.gnome.org/show_bug.cgi?id=685555