Subject: CVS commit: [netbsd-3] src/lib/libpthread
To: None <source-changes@NetBSD.org>
From: Matthias Scheler <firstname.lastname@example.org>
Date: 06/13/2006 22:31:24
Module Name: src
Committed By: tron
Date: Tue Jun 13 22:31:24 UTC 2006
src/lib/libpthread [netbsd-3]: pthread_sig.c
Pull up following revision(s) (requested by chuck in ticket #1376):
lib/libpthread/pthread_sig.c: revision 1.46
sigtimedwait: if we collect a queued signal via pt_siglist, do not
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:
- 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.
To generate a diff of this commit:
cvs rdiff -r126.96.36.199 -r188.8.131.52 src/lib/libpthread/pthread_sig.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.