Patch to allow more granular aborting.
nisse at lysator.liu.se
Mon Mar 14 15:31:29 CET 2011
Theo Schlossnagle <jesus at omniti.com> writes:
> If you know, for a fact, that all failed allocations are termination
> worthy -- I could do this instead.
After a look in the documentation, I see that the allocation functions
are expected to never return NULL. That's why the default functions
(which you patched) call abort on failure, rather than returning NULL.
> 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).
There are things like sigsetjmp, but I'm not sure how safe that is or
how it reallly works.
I agree that providing using a callback function seems more robust than
catching the signal. But then, I think it would make sense to invoke
that callback instead of (or at least before) raising SIGFPE signal.
>> 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.
I'm not following you here. If you run out of memory first, the overflow
conditions (in mpz/realloc.c) will never happen. They could happen,
e.g., if you have two operands of size close to the limit which do fit
in memory, and try to compute their product, of a size which exceeds the
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
More information about the gmp-devel