Problem with signal 0 being delivered to SIGUSR1 handler

Konstantin Belousov kostikbel at gmail.com
Fri Nov 22 18:39:53 UTC 2013


On Fri, Nov 22, 2013 at 02:35:53PM +0100, Jilles Tjoelker wrote:
> This analysis suggests an easier approach: just move the check for
> deferred_siginfo.si_signo == 0 downward. If __fillcontextx2 or sysarch
> need to be looked up by rtld, the resulting _thr_ast() will invoke the
> signal handler and the original call to check_deferred_signal() will do
> nothing.
> 
> This patch fixes the problem for me on stable/9 and head.
> 
> Index: lib/libthr/thread/thr_sig.c
> ===================================================================
> --- lib/libthr/thread/thr_sig.c	(revision 258178)
> +++ lib/libthr/thread/thr_sig.c	(working copy)
> @@ -326,12 +326,12 @@ check_deferred_signal(struct pthread *curthread)
>  	uc_len = __getcontextx_size();
>  	uc = alloca(uc_len);
>  	getcontext(uc);
> -	if (curthread->deferred_siginfo.si_signo == 0)
> -		return;
>  	__fillcontextx2((char *)uc);
>  	act = curthread->deferred_sigact;
>  	uc->uc_sigmask = curthread->deferred_sigmask;
>  	memcpy(&info, &curthread->deferred_siginfo, sizeof(siginfo_t));
> +	if (curthread->deferred_siginfo.si_signo == 0)
> +		return;
>  	/* remove signal */
>  	curthread->deferred_siginfo.si_signo = 0;
>  	handle_signal(&act, info.si_signo, &info, uc);
> 

I do not like this. It is similar to what I did initially when I
debugged the problem, but the duplicated calls to getcontext(2) and
sysarch(2) stayed out as a sore in ktrace. I also do not like the fact
that, with the change, signal is delivered from an rtld context.

If taking such road, the fix would be to add __fillcontext2() to
_rtld_init(), but I described the reason for other fix in the initial
response.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20131122/89b36112/attachment.sig>


More information about the freebsd-hackers mailing list