mutex thread, thus leaving a thread sleeping on an unlocked mutex.
Reviewed by myself and Christos.
Problem reported by Arne H. Juul, arnej at pvv dot ntnu dot no,
in PR 26208. This fix represents option 1 presented in the PR.
forget to clear it out of pt_siglist, otherwise we will keep getting
it over and over again. fixes a problem introduced in rev 1.43.
problem observed with mysqld where sending it a SIGHUP after it has
set an alarm (e.g. due to some package like rt3 using it) caused the
signal handler thread to go into a tight loop (collecting a SIGALRM
[via sigwait() in mysqld.cc] that would not go away due to the above
issue). mysqld appears to get a SIGHUP when /etc/rc exits, so it
can go into this tight loop after a reboot (but not if you restart
it by hand). the bad sequence is:
/etc/rc runs:
- starts mysqld
- starts web server with rt3 fastcgi starts
- fastcgi/rt3 talks to mysqld (causing it to set an alarm)
- /etc/rc exits, SIGHUP goes to mysqld
- mysqld catches SIGHUP, signal handler thread gets
stuck in loop (database continues to operate, slowly).
you can also trigger the problem by sending mysqld a SIGHUP by hand after
you've caused it to set an alarm by connecting to it.
the process' signal mask -- this ends up in a no-op.
Use the system call directly instead.
(This might be done in pthread_sig.c, but for now I wanted a simple
patch which is easily tested and pulled up.)
so that the main thread is not different from others.
as a side effect, fix memory leak in pthread_create on error.
- make pthread__stackid_setup return a error rather than calling err(2).
locations:
- Don't declare pthread__switch_away global
- Do the PIC dance for pthread__switch_return_point and
pthread__locked_switch. Ideally these (and other) symbols would
be hidden.
Thanks to uwe@, dyoung@ and elad@ for help.
XXX sh3 is still to be done.
XXX vax does strange things.
any threads are created turned out to be not such a good idea.
there are stronger requirements on what has to work in a forked child
while a process is still single-threaded. so take all that stuff
back out and fix the problems with single-threaded programs that
are linked with libpthread differently, by checking if the library
has been started and doing completely different stuff if it hasn't been:
- for pthread_rwlock_timedrdlock(), just fail with EDEADLK immediately.
- for sem_wait(), the only thing that can unlock the semaphore is a
signal handler, so use sigsuspend() to wait for a signal.
- for pthread_mutex_lock_slow(), just go into an infinite loop
waiting for signals.
I also noticed that there's a "sem2" test that has never worked in its
single-threaded form. the problem there is that a signal handler tries
to take a sem_t interlock which is already held when the signal is received.
fix this too, by adding a single-threaded case for sig_trywait() that
blocks signals instead of using the userland interlock.
if the target thread is a zombie.
in all the functions that didn't do so already, verify a pthread_t before
dereferencing it (under #ifdef ERRORCHECK, since these checks are not
mandated by the standard).
clean up some debugging stuff.
ad