This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Fwd: failure notice]


>Submitter-Id:	net
>Originator:	Robert Sim
>Organization:
  Robert Sim
  http://www.cim.mcgill.ca/~simra
 
>
>Confidential:	no
>Synopsis:	semaphores deadlock on pthread exit.
>Severity:	non-critical
>Priority:      low
>Category:	libc
>Class:		sw-bug=20
>Release:	libc-2.2.93
>Environment:

Host type: i386-redhat-linux-gnu
System: Linux Beren.Simra.Net 2.4.20 #1 Fri Jan 31 12:07:25 EST 2003 i686 i=
686 i386 GNU/Linux
Architecture: i686

Addons: c_stubs glibc-compat linuxthreads
Build CFLAGS: -march=3Di386 -freorder-blocks -DNDEBUG=3D1 -g -O3
Build CC: gcc
Compiler version: 3.2 20020903 (Red Hat Linux 8.0 3.2-7)
Kernel headers: 2.4.9-9
Symbol versioning: yes
Build static: yes
Build shared: yes
Build pic-default: no
Build profile: yes
Build omitfp: no
Build bounded: no
Build static-nss: no

>Description:

You may or may not agree with me that this is a bug, but judging from
the comments in linuxthreads/spinlock.h, line 208, someone does agree
with me.
On pthread_exit(), __pthread_destroy_specifics() is called.
In specific.c:197 __pthread_destroy_specific calls __pthread_lock()
and then two lines later calls free() with the lock still enabled.

The problem is that you cannot guarantee that a user-supplied free()
will not call a pthread function that calls __pthread_lock() (for
example, sem_wait() might via
__pthread_set_own_extricate_if(). The ElectricFence library does just
that).  I'm not sure what the standard dictates about the state of
semaphores inside pthread_exit(), but it would certainly be preferable
if they could be used.  mutexes don't appear to suffer the same problem.

>How-To-Repeat:

Unfortunately, I've had some difficulty duplicating the problem
outside of a large system (I'm sure you hear that all the time).
Clearly, from the logic above, if a user-supplied free() calls
sem_wait(), and the semaphore conditions are such that
_set_own_extricate_if() is called (there are multiple entry points),
then pthread_exit() will deadlock.  The trick to reproducing is to get
one thread to pthread_exit() at the same time another malloc()'s or
free()'s using the ElectricFence library.

>Fix:
I don't understand the internals to semaphore well enough to see how
it could be re-engineered to not call thread_lock.  I think the
locking in pthread_exit() is probably necessary.  At issue is
whether or not it's reasonable to expect free() to not do any
semaphore locking. Incidentally, I've patched the EFence lib to use a
mutex, rather than a semaphore, and it works
great. http://www.cim.mcgill.ca/~simra/software/ElectricFence/.=20



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]