SIGINT, longjmp

Eric S. Raymond esr at
Wed Jan 27 06:08:54 UTC 2016

Hal Murray <hmurray at>:
> esr at 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 receipt of a signal the register contect
is saved, the handler is called, then on exit the register context is

It probably does follow that you don't want to longjmp() out of a signal
handler; hidden context like signal block masks mightnot be restored.
I note that the GPSD code does not do this.  I think I used to know details
about this that I've forgotten.

> > The right way to think about setjmp()/longjmp() is as a save/restore of the
> > processor's register state, including  the stack and frame pointers.  It
> > doesn't have the concurrency issues that threads do because it doesn't alter
> > static memory or the heap.
> It doesn't alter the heap, but it doesn't restore it either.


> Anything that calls malloc is an opportunity for a storage leak.  Jmp-ing 
> from a signal handler yanks you out of the middle of a routine without any 
> opportunity for cleanup.


> I suspect getaddrinfo masks or intercepts SIGINT, but I haven't found 
> anything like that in the man pages.  The symptom is that ^C doesn't work 
> right away but does work after several seconds, a reasonable time for a DNS 
> lookup if you need to retransmit or have a bloated link.

Ah, it's probably doing a sigsuspend(2).
		<a href="">Eric S. Raymond</a>

More information about the devel mailing list