Application hangs in pthread_cond_timedwait()
Issue
o Application remains sleeping in __pthread_cond_timedwait() indefinitely.
(gdb) bt
#0 0x000003ffad78c40e in __pthread_cond_timedwait (cond=0x3ffa8007d40, mutex=0x3ffa8007d70, abstime=0x3ffad2fe368) at pthread_cond_timedwait.c:166
#1 0x000003ffac9067a6 in j9thread_park () from /root/home/jakrishn/java/jre/lib/s390x/default/libj9thr24.so
#2 0x000003ffa10eedaa in jclCallThreadPark () from /root/home/jakrishn/java/jre/lib/s390x/default/libjclscar_24.so
o From strace of the process we see that it's sleeping on a futex.
12395 22:03:59.616995 futex(0x3ffb4007e04, FUTEX_WAIT_PRIVATE, 5, NULL <unfinished ...>
12400 22:03:59.638015 futex(0x3ffb4007e04, FUTEX_CMP_REQUEUE_PRIVATE, 1, 2147483647, 0x3ffb4006d20, 6 <unfinished ...>
12395 22:03:59.648902 futex(0x3ffb4007e04, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 7, {1489701840, 648890000}, ffffffff <unfinished ...>
o We can convert the futex timeout to wall time.
# TZ=UTC date -d @1489701840
Thu Mar 16 22:04:00 UTC 2017
o The strace output continues past 22:04 but the futex does not timeout and the process remains sleeping. This is critical detail in identifying if a system is affected by this bug as the futex call itself is expected behavior.
Environment
o RHEL 7.3 - kernel-3.10.0-514.el7
o RHEL 7.2 - kernel-3.10.0-327.el7
o zLinux
o Potentially other architectures
Subscriber exclusive content
A Red Hat subscription provides unlimited access to our knowledgebase, tools, and much more.
