I found the glibc-users mailing list. They explained the problem to me. As
far as I can tell, there isn't a clean fix.
The basic problem is that signal handlers can't legally call many routines.
It's similar to the thread-safe issue but not mentioned on individual man
pages. From signal (7)
> Ah, it's probably doing a sigsuspend(2).
I doubt it. That ties up your process/thread waiting for a signal. If you
want to wait for IO, there are simpler ways.
My guess was sigprocmask(2). They way that I discovered that somebody was
masking SIGINT was using it to read the current mask.
Hal Murray :
>
> e...@thyrsus.com said:
> > I don't know of any functions that are specifically unsafe around setjmp()/
> > longjmp().
>
> The interesting case is longjmp-ing from a signal handler.
Right. I believe the way a signal handler works is actually like a
setjmp/longjmp; that is, on re
e...@thyrsus.com said:
> I don't know of any functions that are specifically unsafe around setjmp()/
> longjmp().
The interesting case is longjmp-ing from a signal handler.
> The right way to think about setjmp()/longjmp() is as a save/restore of the
> processor's register state, including the
Hal Murray :
> I'm fishing for a list of routines that shouldn't be used with longjmp
> similar to the list that shouldn't be used with threads, or rather for the
> discussion of that list.
I don't know of any functions that are specifically unsafe around
setjmp()/longjmp().
The right way to th
Hal Murray :
> I haven't figured out if this is a bug in getnameinfo or if longjmp-ing is
> basically evil.
I wouldn't say "evil" exactly, but...remember my caveats about signal handlers?
They apply.
--
http://www.catb.org/~esr/";>Eric S. Raymond
_
k...@roeckx.be said:
> Why do you set up a signal handler for this, and don't let the OS take care
> of it?
> Or alternativly, just call _exit() from the signal handler.
It's not trying to exit, just get out of a long running command.
ntpq has two long-running commands. (Maybe more.)
One is
k...@roeckx.be said:
> I want to add that it likely does at least something with the signal
> handlers so that it can time out.
You don't need signals to time out on network activity. Most reads/writes
have a timeout option. I forget the details. It's been a long time. If
that doesn't work
On Tue, Jan 26, 2016 at 11:03:01PM +0100, Kurt Roeckx wrote:
> > I haven't found anyplace in our code that messes with the signal mask. I
> > could easily be overlooking something that will be obvious in hindsight.
>
> Maybe getnameinfo() does.
I want to add that it likely does at least somethi
On Tue, Jan 26, 2016 at 01:38:52PM -0800, Hal Murray wrote:
>
> k...@roeckx.be said:
> > It's not clear to me when this longjmp() is called. But if changing to
> > siglongjmp() fixed it, it seems the signal handling got changed in between?
>
> It's called from the ^C signal handler. It's the b
k...@roeckx.be said:
> It's not clear to me when this longjmp() is called. But if changing to
> siglongjmp() fixed it, it seems the signal handling got changed in between?
It's called from the ^C signal handler. It's the brute force way of
terminating a command.
I haven't found anyplace in o
On Tue, Jan 26, 2016 at 01:07:04PM -0800, Hal Murray wrote:
>
> The problem is that somebody is masking off SIGINT. It works if I replace
> setjmp+longjmp with sigsetjmp+siglongjmp.
>
> The SIGINT handler was getting called with SIGINT masked off. That seems a
> bit strange. It was coming fr
The problem is that somebody is masking off SIGINT. It works if I replace
setjmp+longjmp with sigsetjmp+siglongjmp.
The SIGINT handler was getting called with SIGINT masked off. That seems a
bit strange. It was coming from deep within getnameinfo.
I haven't figured out if this is a bug in g
13 matches
Mail list logo
