Pull request: Raise SIGFPE instead of abort in __gmp_exception`

Yichao Yu yyc1992 at gmail.com
Sat Jan 30 16:47:05 UTC 2016


>
> Can you suggest and test a workaround of that form?

I believe my original patch "works" on osx although it does have
undefined bahavior. I don't really have a MAC but I can probably find
someone that does to help.

>
>> 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.

dlsym?

>
>> 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.

I agree. I'm not particularly familiar with out usage of GMP. If these
errors are easy to detect in advance, we should probably do that
(given that our machine integer division is already doing that).
Having a error callback would still be better if we are calling other
libraries that use gmp though.

>
> 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

Right, which is why I'm saying it's better than the current situation.
(although not ideal)

> some thread local state in the allocation functions, so you can
> deallocate temporary storage when terminating the thread?

We have a tracing GC so leaking of julia memory isn't an issue. Memory
allocated by GMP might be leaking though. (which is hopefully better
than termination)

>
> 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

Agree. The API looks good to me. It's still global but is much better
than using a signal.

> 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.


More information about the gmp-devel mailing list