[kaffe] Bug Report: BigInteger.toString() fails for large numbers
guilhem at kaffe.org
Wed Apr 21 23:13:02 PDT 2004
Alan Eliasen wrote:
> I've uncovered more information on the locks and crashes we've been getting
>with BigInteger.toString() when Kaffe is compiled with the GMP libraries. I
>think that the problem is fixed, and here are the steps that we'll probably
>need to document.
As you have noticed in GMP, it is using alloca and so induces stack
overflows very quickly for big numbers. Your fix is a solution however I
am trying to implement a real stack overflow error reporting that should
fix all the problems. Increasing stack space using kaffe command line
option should not affect the problem as the stack space for the main
thread is handled by the OS kernel. To increase it you need to change
'ulimit -s'. In the cvs I have changed the way the stack size is
computed so it should work on most unixes (though I've kept the old
behaviour for the other systems). As soon as the regression tests is
passing I'll tell you.
Thank you again for digging into this bug,
> In the GMP documentation at
> I found the following:
> "alloca is reentrant and fast, and is recommended, but when working with
>large numbers it can overflow the available stack space, in which case one of
>the two malloc methods will need to be used. Alternately it might be possible
>to increase available stack with limit, ulimit or setrlimit, or under DJGPP
>with stubedit or _stklen. Note that depending on the system the only
>indication of stack overflow might be a segmentation violation."
> Since using alloca is the default build option for GMP, it's bound to fail
>for very large numbers by overflowing the stack. (alloca is used for
>allocating internal GMP temporary data.) So, if you're going to use large
>numbers, GMP *must* be built using the configure option:
> ./configure --enable-alloca=malloc-reentrant
> In addition, I found that I had two versions of the GMP libraries on my
>system. One was in /usr/lib, but the default when building and installing GMP
>is to put it in /usr/local/lib. Kaffe was picking up the version in /usr/lib.
>So, after installing to /usr/local/lib, I had to change the options passed to
>the Kaffe configure script to:
>./configure --with-includes=/usr/local/include --with-libraries=/usr/local/lib
> (or wherever your GMP header files and libraries are.)
> And then did a make (clean) of Kaffe. (Is there a better way to specify
>the location of the GMP libraries?)
> I can now run the test programs I posted before without halts or crashes.
>The size of the numbers that can be computed appears to be only limited by the
>heap space--adding more heap space by using -Xmx128M allows me to calculate
>very large numbers (2^33,000,000 and above) (It seems to fail with a
>NullPointerException when the numbers get too big for memory, which is
>probably not the right error, but it seems to work otherwise.)
> I think this information should be added to the documentation about
>compiling with GMP, probably to
> (which should probably go into more detail about whether Kaffe needs GMP
>libraries at compile-time or .so files at runtime. Can this vary depending on
>how you build Kaffe?)
> Anyone building a Kaffe package should be sure to compile GMP with these
>options. I can write something up--just let me know who to send it to.
>Thanks to everyone for your help.
> By the way, using Kaffe, Frink ( http://futureboy.homeip.net/frinkdocs/ )
>can calculate things in less than a minute that require days or weeks
>(literally) using Sun's VM. Now that's a success story.
More information about the kaffe