Re: CVS commit: src/regress/lib/libc/siginfo/sigfpe

[christos%zoulas.com@localhost (Christos Zoulas)]

On Feb 18,  9:21pm, M.Drochner%fz-juelich.de@localhost (Matthias Drochner) 
wrote:
-- Subject: Re: CVS commit: src/regress/lib/libc/siginfo/sigfpe

| 
| christos%astron.com@localhost said:
| > These are contradictions and defects in the current standard:
| >     http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1318.htm 
| 
| Uhm - committees...
| As I see it there are two issues mixed:
| (a) whether longjmp from (non-nested) signal handlers generally
|     works and leads to defined results, and
| (b) whether it is a good idea to do it, considering that every
|     function which is called while a setjmp() is active, and
|     the signal in question is not masked, and which can also
|     be called after the longjmp() from the signal handler
|     needs to be reentrant
| 
| > 
https://www.securecoding.cert.org/confluence/display/seccode/SIG32-C.+Do+not+call+lo
| > ngjmp%28%29+from+inside+a+signal+handler
| 
| That's arguably a tricky one but at the end it is just a programmer
| error because log_message() is not reentrant.
| It also suggests to answer (b) with "no" in most cases -- unless
| the window where setjmp() is active and the signal in question
| is not masked is well controlled.
| 
| I'd still answer (a) with "yes" - this is just a technical problem,
| and I thing we do that well (unless an old "sigcontext" signal
| trampoline gets in the way).
| I'd even say the a longjmp is the only way (besides termination)
| to recover halfway sanely from a SIGFPE. Who knows what is left in
| floating point registers in that case which might trap on next
| access, and even if it doesn't trap the results would be unreliable.
| (And imprecise signal delivery makes it worse. I'm not saying that
| imprecise signal delivery is necessarily a bad thing, and I don't
| understand why -mieeefp if forced on alpha code everywhere, but this
| is another matter.)

This all started because if the SIGFPE's in a tight loop froze the
vax.  Programming with setjmp and longjmp is very difficult and
requires a lot of discipline to deal with memory allocation. Tcsh
does this and it has its own malloc/free unwinding code to prevent
memory leaks (grep for cleanup_until in the source). This is
specially tricky to get right in the presence of vfork and stack
based variables (where they can be free'd twice, both in the parent
and the child). I am not saying it is impossible, I am saying it
is difficult and the "set a sig_atomic_t in the handler and test
for it in main" paradigm is in most cases easier/preferable.

Now to make a SIGFPE handler useful without using siglongjmp() we need
to skip the faulting instruction (setting up registers/memory so that
it does not fault from the user program is a lot more complicated).
I just want to add the ability to do/control this in all archs in a sane
way.

christos