|
From: Mark W. <mj...@re...> - 2016-09-20 09:34:17
|
On Sun, 2016-09-18 at 22:18 +0200, Mark Wielaard wrote: > > On my Linux/Ubuntu box these tests hang even when run natively during the > > fourth testcase described as > > "destroy a barrier that has waiting threads". According to POSIX [1]: > > "...The results are undefined if *pthread_barrier_destroy*() is called when > > any thread is blocked on the barrier... " > > which bar_bad precisely does. > > > > Perhaps a timer which would time out this hang would be handy here. > > My apologies for not recognizing this earlier. We carry a patch in Fedora > to work around this test hang. The workaround is attached to this bug > report: https://bugsfiles.kde.org/attachment.cgi?id=96765 > > As you can read in that bug report the workaround isn't ideal because > it might still FAIL the test. If someone could take a look at the bug > and proposed patch to see if it can somehow be changed so that it > makes the test reliably pass with older and newer glibc that would be > very appreciated. I checked in my workaround as valgrind svn r15962 (adding a missing exp file in svn r15966, sorry about that). It adds a sleeping thread that tries to unblock the barrier in case the test hangs (plus new exp files that describe that situation). It does seem to unblock the test, but it adds (more) non-determinism that seems to make the test fail more than before. So I kept the bug report open: https://bugs.kde.org/show_bug.cgi?id=358213 Could people check whether with this new testcase the test no-longer hangs and whether or not is passes? If it fails could you double check whether or not it fails always or just sometimes? And if you know why that would be very helpful to know! Thanks, Mark |