Bug 3610 - coredump on pthread_mutex_lock()
Summary: coredump on pthread_mutex_lock()
Status: RESOLVED INVALID
Alias: None
Product: glibc
Classification: Unclassified
Component: nptl (show other bugs)
Version: 2.4
: P2 normal
Target Milestone: ---
Assignee: Ulrich Drepper
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-11-29 12:26 UTC by Jørgen Hovland
Modified: 2016-05-08 14:03 UTC (History)
1 user (show)

See Also:
Host: i686-j-linux
Target: i686-j-linux
Build: i686-j-linux
Last reconfirmed:
fweimer: security-


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jørgen Hovland 2006-11-29 12:26:28 UTC
There is a chance that glibc/nptl is not the cause of this, but I cannot say 
for sure. 
Note that this is glibc 2.5, not 2.4 as stated in the version field.
Thanks

Example 1:
#3  0x000073fc in ?? ()
#4  0xb797181b in *__GI_raise (sig=6) 
at ../nptl/sysdeps/unix/sysv/linux/raise.c:67
#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 
pthread_mutex_lock.c:379


Example 2:
#4  0xb799e577 in *__GI_raise (sig=6) 
at ../nptl/sysdeps/unix/sysv/linux/raise.c:67
#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 
pthread_mutex_lock.c:379

Hardware: dual xeon x64 with hyperthreads
Kernel 2.6.18.1 and 2.6.18.2
Comment 1 Jørgen Hovland 2006-11-29 12:28:03 UTC
The mutex was created with the PTHREAD_MUTEX_RECURSIVE attribute.
Comment 2 Jakub Jelinek 2006-11-29 12:35:52 UTC
Do you have a testcase?
Comment 3 Jakub Jelinek 2006-11-29 12:43:00 UTC
Also, were there calls to pthread_mutexattr_setprotocol?
If not, this sounds like either uninitialized mutex or unitialized mutex
attribute.
Comment 4 Jørgen Hovland 2006-11-29 14:28:37 UTC
pthread_mutexattr_init was not called, just *_settype. Case closed:) Thanks 
for your help.