[quagga-dev 1354] Re: signal handling breaks gdb on NetBSD - fixed in CVS
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
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
> 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
> 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