Bug: deadlock from msyslog
Gary E. Miller
gem at rellim.com
Tue Mar 22 04:07:58 UTC 2016
Yo Hal!
On Mon, 21 Mar 2016 20:23:41 -0700
Hal Murray <hmurray at megapathdsl.net> wrote:
> esr at thyrsus.com said:
> > I just ported in the Classic fix "[Bug 2814] msyslog deadlock when
> > signaled." I think that'll do it for this one.
>
> Is there any software that will check signal handlers to see if they
> call (or call anything that calls) any non-signal-safe routines?
# man signal
"The behavior of signal() varies across UNIX versions, and has also var‐
ied historically across different versions of Linux. Avoid its use:
use sigaction(2) instead."
That bears repeating:
"Avoid its use: use sigaction(2) instead."
You may 'fix' msyslog, but signal() is inherently not thread safe. From
the man page:
"The effects of signal() in a multithreaded process are unspecified."
> The case I'm thinking of is a trap handler that catches a
> fatal error and wants to print out a useful message and then exit
> somewhat cleanly.
Check out "man 7 signal", almost nothing is legal to call from within
a signal. You can't even open() of fopen() anything. About the best you
can do is write(STDERR,) and exit().
RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem at rellim.com Tel:+1 541 382 8588
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160321/a52005ba/attachment.bin>
More information about the devel
mailing list