abort on error - is this being addressed?
marc.glisse at inria.fr
Thu Aug 26 11:38:10 CEST 2010
On Thu, 26 Aug 2010, Allan Chandler wrote:
> GNU MP unconditionally calls abort() on allocation failures,
> which are bound to happen with certain insanely large
> computations. This is unacceptable behaviour for a library and
> reason enough to write your own arbitrary-precision code.
First, notice that any OS that overcommits memory (like Linux unless you
use some option that is not recommended) makes the point moot.
> Has anyone thought of addressing this issue?
It is mentionned in the projects.html file ;-)
> A phased approach of modifying small parts of GMP would minimise
> the chance of damaging the integrity of the code. What I mean by that
> is that we just do one section of the code at a time, as long as the
> call trees are more trees than bushes. I haven't had a good look at
> the code yet so I don't know how tightly integrated it is but it
> may be that we could tackle integer stuff (mpz_*) as a unit, then
> rationals (mpq_*) and so on.
mpn is the obvious place to start.
On Thu, 26 Aug 2010, Niels Möller wrote:
> 1. Have an alternative set of functions where the caller must allocate
> and provide space not only for the result, but also any temporary
> scratch space needed during the computation. Search this list for
> itch/scratch for more info. Some of the low-level functions are
> already written this way, but a lot of work remains.
It looks like the approach with the best chances of success in a not
too distant future.
> 2. Register your own allocation functions with GMP, which detect
> allocation failures. Then, set up a allocation marker and a setjmp
> buffer before each computation which might exhaust memory. On
> failure, have the allocation function not return to gmp, instead, it
> should deallocate all temporary storage (using the above "marker"),
> and longjmp out to abort the computation.
C++ does have some good points...
More information about the gmp-devel