[quagga-dev 1354] Re: signal handling breaks gdb on NetBSD - fixed in CVS

Paul Jakma paul at clubi.ie
Wed Jul 14 12:17:05 BST 2004

On Tue, 13 Jul 2004, Greg Troxel wrote:

> In lib/sigevent.c:quagga_signal_timer, all signals are blocked while
> signal handlers are run.  (I'm not sure why this is necessary, but I'm
> probably missing something.)

Because it examines the quagga_sigevent_master_t structure, one 
member of which, caught, is set from signal context. Now, we could 
possibly drop the blocking altogether actually, if the following two 
operations are atomic on all architectures we care about:

 	(volatile sig_atomic_t) = 0
 	(volatile sig_atomic_t)++

I'm not sure whether they are, so i blocked signals to be safe. If 
those operations are guaranteed atomic, (increment might very well 
be, however I'm not sure the store of 0 would be).

If they are not atomic, the other possibility is to only block the 
specific signal concerned, and only block the comparison and the 
increment. However, that seems like a lot of overhead.

It would be nice though to not run the 'heavy' handler function with 
signals blocked.

>  Even SIGTRAP is blocked, and on NetBSD
> 2.0_BETA2 this seems to work - even for breakpoints.

At a guess, debuggers need to be able to block SIGTRAP from being 
passed to the process being debugged?

>  The sigprocmask
> man page says:
>     The system quietly disallows SIGKILL or SIGSTOP to be blocked.
> I have committed a change to quagga_signal_timer to refrain from
> blocking SIGTRAP.  This should either help people with gdb or be
> harmless.
> I'm curious if others have had trouble with gdb.

Paul Jakma	paul at clubi.ie	paul at jakma.org	Key ID: 64A2FF6A
 	warning: do not ever send email to spam at dishone.st
If you sell diamonds, you cannot expect to have many customers.
But a diamond is a diamond even if there are no customers.
 		-- Swami Prabhupada

More information about the Quagga-dev mailing list