Pull request: Raise SIGFPE instead of abort in __gmp_exception`

[Niels Möller]

Yichao Yu <yyc1992 at gmail.com> writes:

> If I read the patch[1] correctly, the divide by zero is nor performed
> if SIGFPE exists.

You're right, in that case it skips the divide by zero and goes directly
to abort.

>> It's possible to add som OSX workaround, say
>>
>>   #if defined (SIGFPE) && defined (MAC_SOMETHING)
>>
>> But I'd prefer to do that only if there's any real problem. After all,

> There is.

Can you suggest and test a workaround of that form?

> I think the right way is to conditionally (on osx) use `pthread_kill`
> (and link to pthread).

A link dependency on pthread is highly undesirable. *Maybe* if it can be
hidden from users.

> I think another difference that worth clarifying between what we want
> and what is currently assumed in gmp is that we don't really want the
> program to terminate if there's some arithmetic error.

Using a signal handler for that sounds brittle to me. I would strongly
recommend checking for invalid operands (like, if (mpz_sgn(d) == 0)
julia_divide_by_zero_error()) before calling gmp functions which might
divide by zero. Allocation failures are a differnt a more difficult
matter, but there it's probably better to longjmp out of the allocation
function than to raise a signal.

> Of course, using a callback to report the error would be even better.
> However, as you (or someone else) mentioned, having such API would
> probably imply that GMP should still be in a consistent state after an
> error is thrown (and handled)

But you have very similar consistency issues when using a signal
handler. I'm afraid it's going to be a bit brittle. Or are you using
some thread local state in the allocation functions, so you can
deallocate temporary storage when terminating the thread?

> Adding such API and refine it later would still be strictly
> better than the current situation though.

To me it would make sense with something like

  mp_set_error_handler (void (*handler)(enum gmp_error err));

where the current __gmp_exception is the default handler. Still tricky
to safely use a handler which doesn't terminate the program, but at
least cleaner and more portable than using signal handlers. In
particular, mixing signals and longjmp really makes me uneasy...

Not sure what the other developers think?

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.