John Polstra cf98e66403 Fix a bug which could cause programs with user threads packages to ... lock against themselves, causing infinite spinning. Brian Feldman found this problem when testing with Mozilla and supplied the fix, which I have revised slightly. Here is the failure scenario. A thread calls dlopen() and acquires the writer lock. While the thread still holds the lock, a signal is delivered and caught. The signal handler tries to call a function which hasn't been bound yet. It thus enters the dynamic linker and tries to acquire the reader lock. Since the writer lock is already held, it will spin forever in the signal handler. The thread holding the lock won't be able to progress and release the lock. The solution is to block almost all signals while holding the exclusive lock. A similar problem could conceivably occur in the opposite order. Namely, a thread is holding the reader lock and then a signal handler calls dlopen() or dlclose() and spins waiting for the writer lock. We deal with this administratively by proclaiming that signal handlers aren't allowed to call dlopen() or dlclose(). Actually we don't have to proclaim a thing, since signal handlers aren't allowed to call any system functions except those which are explicitly permitted. Submitted by: Brian Fundakowski Feldman <green>		2000-07-17 17:18:13 +00:00
..
lockdflt.c	Fix a bug which could cause programs with user threads packages to	2000-07-17 17:18:13 +00:00
Makefile.inc
reloc.c
rtld_machdep.h
rtld_start.S