Date: Thu, 06 Mar 2008 11:10:00 -0600 From: Derek Ragona <derek@computinginnovations.com> To: Martin McCormick <martin@dc.cis.okstate.edu>, freebsd-questions@freebsd.org Subject: Re: SIGHUP and Program Flow in a 6.2 Application Message-ID: <6.0.0.22.2.20080306110721.024330b0@mail.computinginnovations.com> In-Reply-To: <200803061346.m26DkTLS042008@m.it.okstate.edu> References: <200803061346.m26DkTLS042008@m.it.okstate.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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
>sense.
>
> 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
>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@freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-questions
>To unsubscribe, send any mail to "freebsd-questions-unsubscribe@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6.0.0.22.2.20080306110721.024330b0>