SIGHUP and Program Flow in a 6.2 Application

Derek Ragona derek at
Thu Mar 6 17:09:26 UTC 2008

At 07:46 AM 3/6/2008, Martin McCormick wrote:
>         This actually turned out to be a red herring. One of the
>things I had to trace was an attempted read from /dev/ttyd0 in
>which I was trying to go past the actual read. This appears to
>be what thoroughly confused the trace.
>         There was a logic error in the signal handler which
>caused it to never exit and that was what prevented further
>signals. It took me a while to figure all that out but it makes
>         In my tinkering with embedded systems and
>assembly-language programming, one often-times shuts off the
>interrupts first thing during an interrupt handler because
>disaster results if another interrupt comes in while one is
>setting up the jump vector, etc. The signal handler hides all
>those details, but it still has to take care of them.
>         Anyway, when I fixed the logic of the handler, itself
>and did not try to trace it, it does work as one would expect.
>         I appreciate the help as it made me think and re-examine
>what was happening. The man page more or less explains it if you
>know what to look for but it wasn't close enough to what was
>happening here to really help much.

Good to hear you got things working.  Debugging signal handlers and 
interrupt handlers is always a challenge.  I am an old assembly coder too, 
and have done embedded work as well.  It can be very challenging in any 
environment debugging these, particularly with re-entrancy issues.


>Derek Ragona writes:
> >Nothing needs to be in your handler function to continue running simply
> >return from your function.  However, depending on the signal you may wish
> >to call the original signal handler.  Signals like interrupts are chained
> >linked lists of handlers.  You can choose to break the chain, and have only
> >your handler called, or keep the chain intact calling the other handlers.
>In this case, the chain appears to resume on return from the
>routine I called on SIGHUP.
>freebsd-questions at mailing list
>To unsubscribe, send any mail to "freebsd-questions-unsubscribe at"
>This message has been scanned for viruses and
>dangerous content by MailScanner, and is
>believed to be clean.

This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

More information about the freebsd-questions mailing list