Problems with mpz_set_str and huge strings
stefan-usenet at bytereef.org
Mon Jul 6 02:35:54 CEST 2009
Torbjorn Granlund <tg at gmplib.org> wrote:
> Stefan Krah <stefan-usenet at bytereef.org> writes:
> Torbjorn Granlund <tg at gmplib.org> wrote:
> > Stefan Krah <stefan-usenet at bytereef.org> writes:
> > I'm having memory corruption problems when using mpz_set_str for some huge
> > strings. Valgrind tracks down the problem to an invalid write in __gmpn_sub_n.
> > GMP only supports numbers of 2^31-1 bits or less on a 32-bit computer.
> > Your number is greater than that.
> Actually, I am wrong. 2^32-1 is the intended limit.
> I think your operands should be made to work, since they actually can be
> made to fit into memory.
It appears to be an overflow in mpz/set_str.c, where xsize is ultimately
negative (printf inserted by me):
Breakpoint 3, __gmpz_set_str (x=0xffe034ec, str=0xf7d6d2c2 "", base=10) at set_str.c:126
126 printf("str_size: %u __mp_bases: %f numb_bits+2: %d\n",
str_size: 677741241 __mp_bases: 0.301030 numb_bits+2: 34
129 xsize = (((mp_size_t) (str_size / __mp_bases[base].chars_per_bit_exactly))
(gdb) p 677741241 / 0.301030
$1 = 2251407637.1125803
(gdb) p (long) (677741241 / 0.301030)
$2 = -2043559659
131 MPZ_REALLOC (x, xsize);
(gdb) p xsize
$3 = -67108862
> "There is no practical limit to the precision except the ones implied by the
> available memory in the machine GMP runs on."
> This could be replaced by the actual limits. Then, in the manual the limits
> could be added as a short subsection of "GMP Basics".
> Well, I'd say that 2^32-1 bits is a limit imposed by the hardware on
> 32-bit computers. Sure, on some sense one could have 2^32-1 *bytes*,
> but then only one operand, and nowhere to place the result of any
> arithmetic, and no space for the program.
Yes, of course, but I was thinking 2^31-1 bits.
More information about the gmp-bugs