FAIL nptl/tst-robustpi4
Stefan Liebler
stli@linux.vnet.ibm.com
Thu Jan 26 15:29:00 GMT 2017
Hi,
On s390, I've recognized a FAIL in nptl/tst-robustpi4 in about 16 of
10000 iterations of this testcase.
Does anyone else see failures here, too?
If the test fails, I get:
tst-robustpi4: ../nptl/pthread_mutex_lock.c:424:
__pthread_mutex_lock_full: Assertion `INTERNAL_SYSCALL_ERRNO (e, __err)
!= ESRCH || !robust' failed.
Didn't expect signal from child: got `Aborted'
The mutex is a "robust pi" one, thus the futex-syscall returned ESRCH here.
However, the comment before the assertion claims:
/* ESRCH can happen only for non-robust PI mutexes where
the owner of the lock died. */
The coredumps show that the tf-thread has already finished
and the do_test-thread tried pthread_mutex_lock(&m1) and shall return
EOWNERDEAD (see nptl/tst-robust1.c:202 e = LOCK (&m1);).
But instead the futex syscall returns ESRCH.
and (gdb) p/x m1->__data.__lock
= 0xc0000000
= FUTEX_OWNER_DIED | FUTEX_WAITERS
Furthermore, the coredumps always show an even value in round-variable.
Thus tf is not joined (tst-robust1.c:190) before calling
pthread_mutex_lock(tst-robust1.c:202).
If the do_test-thread waits a bit (e.g. doing something in a loop)
before locking the mutex, the tf-thread has already called
__exit_thread(pthread_create.c:478).
Then m1->__data.__lock is already marked with FUTEX_OWNER_DIED | 0
before calling the futex syscall in pthread_mutex_lock
(pthread_mutex_lock.c:411).
Then the futex syscall takes over the mutex by setting __lock to
FUTEX_OWNER_DIED | do_test-TID and is returning 0.
If I run the test with such a "wait-loop" for several times, I see no fails.
If the do_test-thread locks the mutex before __exit_thread() is called
in tf-thread, the futex syscall sets FUTEX_WAITERS bit and blocks until
tf-thread has exited.
Afterwards 0 is returned and m1->__data.__lock is 0xc0000000
= FUTEX_OWNER_DIED | FUTEX_WAITERS.
If I run the test with a "wait-loop" before pthread_testcancel in
tf-thread for several times as described, I see no fails, too.
It seems as a race between futex- and exit-syscall causes ESRCH result
from futex-syscall.
I see those fails with Linux 4.8 / 4.9 running in a z/VM guest
as well as with 4.6 on a LPAR (but less often).
Bye
Stefan
More information about the Libc-alpha
mailing list