we experience reproducible crashes on SLES11 SP2 with glibc-2.11.3-17-39.1. The app that crashes is a 32bit x86 multithreaded binary. The crash is reproducible and only occurs with glibc-2.11.3-17-39.1.
The crash always occur when the app is stopped, most probably in some cleanup code of glibc.
When the app links to glibc-2.11.3-17-35.4 there are no crashes.
64bit apps appear to be not affected at all.
After the crash the call stack ist always (output of gdb where):
#0 0xffffe430 in __kernel_vsyscall ()
#1 0xf737ee30 in raise () from /lib/libc.so.6
#2 0xf7380765 in abort () from /lib/libc.so.6
#3 0xf7377db8 in __assert_fail () from /lib/libc.so.6
#4 0xf74cd5c5 in __pthread_mutex_cond_lock () from /lib/libpthread.so.0
#5 0xf74c7a6d in __condvar_tw_cleanup () from /lib/libpthread.so.0
#6 0xf752e2e8 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
I was not yet able to provide a test program but due to the fact that only the latest 32bit glibc version seems to be affected I’m pretty sure it’s a glibc bug, most probably in some nptl patch added (or not) between and glibc-2.11.3-17-35.4 and glibc-2.11.3-17-39.1.
Thanks and best regards,
Michael Kwasigroch, Intercope GmbH, Hamburg