Pull request: Raise SIGFPE instead of abort in __gmp_exception`

Yichao Yu yyc1992 at gmail.com
Mon Jan 11 15:31:55 UTC 2016


On Thu, Jan 7, 2016 at 3:45 PM, Niels Möller <nisse at lysator.liu.se> wrote:
> Yichao Yu <yyc1992 at gmail.com> writes:
>
>> We (julia) catches the SIGFPE generated by GMP and raise our own
>> error.
>
> Out of curiosity, what are you doing on error? Display a message and
> exit the process, or do you try to continue? At the very least, you
> could suffer memory leaks, and perhaps leave other gmp objects in an
> inconsistent state.

We essentially `longjmp` to the frame that is setup to catch the error.

>
> Maybe it would be simple and helpful to add a global error callback
> pointer (where you could install a function looking up some thread-local
> storage, if you want something thread-specific). But robust cleanup from

That would work too. (And I guess the default one can throw a FPE so
it should be backward compatible). The handler actually doesn't need
to be thread local but the issue is `raise(SIGFPE)` can raise the
exception on another thread.....

> errors is quite tricky (it has been discussed on list from time to
> time, one possibility is to combine it with custom memory allocators
> with markers, and let the error handler longjmp out and clean up and
> deallocate transient storage).
>
> That said, it sounds reasonable to me to replace abort by raise(SIGFPE).
> A configure check may be needed; I think both abort and raise are ANSI
> C, but I suspect SIGFPE isn't.

Hmm. What about `#ifdef` on `SIGFPE` and `abort` otherwise. This
should be a sane enough default for the even when the custom handler
is added.

>
> Depending on pthreads functions is undesirable.
>
> 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