There is a chance that glibc/nptl is not the cause of this, but I cannot say
Note that this is glibc 2.5, not 2.4 as stated in the version field.
#3 0x000073fc in ?? ()
#4 0xb797181b in *__GI_raise (sig=6)
#5 0xb79731e8 in *__GI_abort () at abort.c:88
#6 0xb796af2c in *__GI___assert_fail (assertion=0xb7a86b04 "new_prio == -1 ||
(new_prio >= __sched_fifo_min_prio && new_prio <= __sched_fifo_max_prio)",
file=0xb7a86ae0 "tpp.c", line=63,
function=0xb7a86ae6 "__pthread_tpp_change_priority") at assert.c:78
#7 0xb7a84db2 in __pthread_tpp_change_priority (previous_prio=-1,
new_prio=3825) at tpp.c:61
#8 0xb7a7db5b in __pthread_mutex_lock (mutex=0x81162fc) at
#4 0xb799e577 in *__GI_raise (sig=6)
#5 0xb79a00ea in *__GI_abort () at abort.c:88
#6 0xb799782c in *__GI___assert_fail (assertion=0x6 <Address 0x6 out of
bounds>, file=0x6 <Address 0x6 out of bounds>, line=6,
function=0xb7abbf78 "__pthread_tpp_change_priority") at assert.c:78
#7 0xb7ab9ddf in __pthread_tpp_change_priority (previous_prio=-1,
new_prio=1527) at tpp.c:61
#8 0xb7ab27b5 in __pthread_mutex_lock (mutex=0x908db1c) at
Hardware: dual xeon x64 with hyperthreads
Kernel 188.8.131.52 and 184.108.40.206
The mutex was created with the PTHREAD_MUTEX_RECURSIVE attribute.
Do you have a testcase?
Also, were there calls to pthread_mutexattr_setprotocol?
If not, this sounds like either uninitialized mutex or unitialized mutex
pthread_mutexattr_init was not called, just *_settype. Case closed:) Thanks
for your help.