SIGHUP and Program Flow in a 6.2 Application
derek at computinginnovations.com
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 freebsd.org mailing list
>To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"
>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