Patch to allow more granular aborting.

[Theo Schlossnagle]

On Mon, Mar 14, 2011 at 5:02 AM, Niels Möller <nisse at lysator.liu.se> wrote:
> Theo Schlossnagle <jesus at omniti.com> writes:
>
>> Currently, libgmp treats out-of-memory and FPE errors as the same type
>> of abort as consistency issues.  This makes it hard to integrate into
>> long running processes where you want to catch and react to these
>> errors.
>
> I don't quite understand the need. Maybe it would help if you explain
> what kind of reaction you are thinking about.
>
> 1. About out-of-memory.
>
> Can you explain why the current interface doesn't suffice? You can
> provide your own allocation function, and make them raise an error in
> any way you please on failure, instead of returning NULL to the caller.

There are places, I presume that you get a failed allocation and
handle gracefully.  I really only want the cases that place libgmp
into a "cannot continue" state.

If you know, for a fact, that all failed allocations are termination
worthy -- I could do this instead.

> 2. And this patch, for __gmp_invalid_operation
>
> --- a/invalid.c Sat Mar 12 22:38:49 2011 +0100
> +++ b/invalid.c Sun Mar 13 17:50:40 2011 -0400
> @@ -68,5 +68,5 @@
>  __gmp_invalid_operation (void)
>  {
>   raise (SIGFPE);
> -  abort ();
> +  __gmp_internal_abort ();
>  }
>
> I would expect that raise (SIGFPE) never returns, and view the abort
> call as a sanity check in case that signal is ignored for some reason.
> At least I have some difficulty imagining how to write a handler for
> this signal that can return in any useful way. Using signals at all has
> some drawbacks, but if we keep that (like you do in your patch),
> wouldn't it be easier to install a signal handler which does what you
> want and doesn't return, than to let the signal handler return to GMP
> and then have GMP call your gmp_internal_abort_code function pointer?

I can't do what I want from a signal handler, it isn't safe to throw
an exception there as we'd be in an alternate stack (most likely).

So, instead, I set a flag in the signal handler and return, then my
abort function gets called.

> 3. The final (I think) case is the mpz_t overflow conditions. Not sure
> how to get there without first running out of memory, though.

This is the case I was hitting. It was an overflow condition that
manifested as an OOM.



-- 
Theo Schlossnagle

http://omniti.com/is/theo-schlossnagle