- Subject: libc/1662: Segmentation fault in pthread_mutex_unlock
- From: stsikin at interbase dot com
- Date: Sat Mar 25 17:07:32 2000
Topics:
libc/1662: Segmentation fault in pthread_mutex_unlock (__pthread_unlock)
----------------------------------------------------------------------
Date: Tue, 21 Mar 2000 17:55:19 -0500
From: stsikin@interbase.com
To: bugs@gnu.org
Subject: libc/1662: Segmentation fault in pthread_mutex_unlock (__pthread_unlock)
Message-Id: <200003212255.RAA07717@delysid.gnu.org>
>Number: 1662
>Category: libc
>Synopsis: Segmentation fault in pthread_mutex_unlock (__pthread_unlock)
>Confidential: no
>Severity: critical
>Priority: medium
>Responsible: libc-gnats
>State: open
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Tue Mar 21 18:00:03 EST 2000
>Last-Modified:
>Originator: stsikin@interbase.com
>Organization:
net
>Release: 2.1.2
>Environment:
Linux linux14 2.2.12-20smp #1 SMP Mon Sep 27 10:34:45 EDT 1999 i686 unknown
Red Hat 6.1
kernel-2.2.12-20
glibc-2.1.2-11
>Description:
The application crashes when it is trying to unlock a mutex:
========================================================================
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 28837]
Program received signal SIGSEGV, Segmentation fault.
__pthread_unlock (lock=0x8253ed8) at spinlock.c:84
spinlock.c:84: No such file or directory.
(gdb) back
#0 __pthread_unlock (lock=0x8253ed8) at spinlock.c:84
#1 0x40141b5f in __pthread_mutex_unlock (mutex=0x8253ec8) at mutex.c:126
#2 0x80634d9 in ISC_event_wait (count=1, events=0xbe3ffd08,
values=0xbe3ffd0c, micro_seconds=60000000, timeout_handler=0,
handler_arg=0x0) at isc_sync.c:1926
#3 0x8052163 in thread (flags=0x2) at server.c:5403
#4 0x40140eca in pthread_start_thread (arg=0xbe3ffe60) at manager.c:213
=========================================================================
Here is the linux threads sources:
[spinlock.c]:
...
62 void internal_function __pthread_unlock(struct _pthread_fastlock * lock)
63 {
64 long oldstatus;
65 pthread_descr thr, * ptr, * maxptr;
66 int maxprio;
67
68 again:
69 oldstatus = lock->__status;
70 if (oldstatus == 0 || oldstatus == 1) {
71 /* No threads are waiting for this lock. Please note that we also
72 enter this case if the lock is not taken at all. If this wouldn't
73 be done here we would crash further down. */
74 if (! compare_and_swap(&lock->__status, oldstatus, 0, &lock->__spinlock))
75 goto again;
76 return;
77 }
78 /* Find thread in waiting queue with maximal priority */
79 ptr = (pthread_descr *) &lock->__status;
80 thr = (pthread_descr) oldstatus;
81 maxprio = 0;
82 maxptr = ptr;
83 while (thr != (pthread_descr) 1) {
--->84 if (thr->p_priority >= maxprio) {
85 maxptr = ptr;
86 maxprio = thr->p_priority;
87 }
88 ptr = &(thr->p_nextlock);
89 thr = *ptr;
90 }
...
...
Attempt to find thread in waiting queue with maximal priority ends up
with 'segmentation violation' on line 84 because 'thr' is equal to
zero...
I think this is a bug in linux threads. The thr->p_nextlock can be 0,1
or ADDR. Hence the loop condition (line 83) can be changed as follows:
83 while ((thr != (pthread_descr) 1) && (thr != (pthread_descr) 0)) {
84 if (thr->p_priority >= maxprio) {
85 maxptr = ptr;
86 maxprio = thr->p_priority;
87 }
88 ptr = &(thr->p_nextlock);
89 thr = *ptr;
90 }
When I applied the fix, the SIGSEGV went away.
Regards,
- -Stanislav Tsikin
>How-To-Repeat:
No test case, sorry..
>Fix:
>Audit-Trail:
>Unformatted:
------------------------------
End of forwardEuFUtd Digest
***************************