Bug 329 - linuxthreads.old: Issues with pthread_mutex_lock()
Summary: linuxthreads.old: Issues with pthread_mutex_lock()
Status: RESOLVED FIXED
Alias: None
Product: uClibc
Classification: Unclassified
Component: Threads (show other bugs)
Version: 0.9.30.1
Hardware: PC Linux
: P5 normal
Target Milestone: 0.9.32
Assignee: unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-05-12 08:37 UTC by Natanael Copa
Modified: 2011-04-29 11:43 UTC (History)
2 users (show)

See Also:
Host: x86
Target: x86
Build: x86


Attachments
stress.c (17.67 KB, text/plain)
2009-05-12 08:37 UTC, Natanael Copa
Details
testfrmw.c (1.78 KB, text/plain)
2009-05-12 08:37 UTC, Natanael Copa
Details
testfrmw.h (2.36 KB, text/plain)
2009-05-12 08:38 UTC, Natanael Copa
Details
posixtest.h (440 bytes, text/plain)
2009-05-12 08:38 UTC, Natanael Copa
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Natanael Copa 2009-05-12 08:37:31 UTC
Created attachment 313 [details]
stress.c

Asterisk segfaults fairly often and it seems like very often its related to pthread_mutex_lock(). I found a stress test in the http://posixtest.sourceforge.net/ test suite that seems to be able to trigger some bugs in the linuxthreads.old. It returns:

Test stress.c FAILED: Got a non-zero value - two threads owns the mutex
Comment 1 Natanael Copa 2009-05-12 08:37:59 UTC
Created attachment 315 [details]
testfrmw.c
Comment 2 Natanael Copa 2009-05-12 08:38:31 UTC
Created attachment 317 [details]
testfrmw.h
Comment 3 Natanael Copa 2009-05-12 08:38:51 UTC
Created attachment 319 [details]
posixtest.h
Comment 4 Natanael Copa 2009-05-12 08:41:29 UTC
compile with:  gcc -o stress stress.c -lpthread

run the test in background, './stress &' and send -USR1 to the processes 'killall -USR1 stress'

Comment 5 Timo Teräs 2009-05-12 14:55:03 UTC
One problem is (for PTHREAD_MUTEX_ERRORCHECK_NP and PTHREAD_MUTEX_TIMED_NP) types that __pthread_alt_lock() uses wait_node on stack, but does not protect against signals. It is possible for the wait_node on stack to be left on the wake up queue, but the pthread_alt_lock to be unwinded from stack causing bad things.

I suspect same can happen with __pthread_lock(). However, __pthread_lock() does not link stack allocated items on the wait list, so it's harder to debug. But I suspect similar race condition exists there.

manpage says pthread_mutex_lock is not a cancellation point. Shouldn't we just block signals there?
Comment 6 Natanael Copa 2010-05-19 06:38:01 UTC
With NPTL this stress test passes.

I think we can close this bug. Thanks!
Comment 7 Bernhard Reutner-Fischer 2011-04-29 11:43:23 UTC
Works with NPTL