GNOME Bugzilla – Bug 334943
make check FAIL: threadpool-test
Last modified: 2011-02-18 15:49:28 UTC
Please describe the problem: build on sparc solaris 9 gcc version 4.0.2 make finishes make check ** ERROR **: file threadpool-test.c: line 124 (test_thread_sort_entry_func): assertion failed: (last_thread_id <= thread_id) aborting... FAIL: threadpool-test ... ===================================================================== 1 of 47 tests failed Please report to http://bugzilla.gnome.org/enter_bug.cgi?product=glib ===================================================================== make[4]: *** [check-TESTS] Error 1 Steps to reproduce: 1. make check 2. 3. Actual results: ** ERROR **: file threadpool-test.c: line 124 (test_thread_sort_entry_func): assertion failed: (last_thread_id <= thread_id) aborting... FAIL: threadpool-test ... ===================================================================== 1 of 47 tests failed Please report to http://bugzilla.gnome.org/enter_bug.cgi?product=glib ===================================================================== make[4]: *** [check-TESTS] Error 1 Expected results: no failures Does this happen every time? yes Other information:
Hmm, I have seen this too. And I think the logic behind last_failed is flawed. I think it is possible for more than one item to appear out-of-order, if the queue runs empty before the next item is pushed. Martyn ?
To be more precise, I have seen this fail in our build system, on >=8-way machines. Here is the patch I used to make it pass.
Created attachment 61618 [details] [review] a patch
As rambokid points out, even with this patch, the out-of-order detection logic is still vulnerable to scheduler races: <rambokid> mclasen: that is still scheduler-racy though. the way the test is setup, it will only be non-racy if exactly 1 worker thread is used. <rambokid> mclasen: simply because before the first G_LOCK() the scheduler can decide to exec the threads in any order <mclasen> rambokid: but if all queuing happens before any work is done, you will never run into out-of-order items, or am I missing something ? <rambokid> mclasen: yeah, you're missing the esystem scheduler. if you execute multiple threads in parallel, they can be worked on in any order. so if you start threads 1,2,3,4,5,6,7,8, the system scheduler can decide to work on them in order 8,7,6,5,4,3,2,1, so they'd acquirte the first G_LOCK in the test funciton in wrong order, and the assertion logic gets triggered. <mclasen> ah, thats true
Since we have no way to know which order the system scheduler will decide to exec threads and hence which G_LOCK will get in first, I see only two options: 1. We remove this particualr test. 2. We allow an acceptable level of error. I think we should probably remove the test.
Fine with me
not fine with me though... ;) i think the basic order testing that is accomplished does make sense. it just can't be properly tested in a multi-threaded scenario. so simply limit the number of worker threads to 1 for the duration of the test, that way, the ordering is still checked.
Created attachment 61853 [details] [review] Improves on first patch This patch basically does what Matthias' patch did except I have added to the documentation, added some comments in the code and removed the debugging so 'make check' is less noisy. If you guys are happy with the documentation addition I will go ahead and commit it.
Looks good to me.
Committed.