Very annoying mpz_get_str function Problem !

[Michel Bardiaux]

The Codrinus wrote:
>>This behavior does not *prove* the problem is in mpz_get_str. It is 
>>conceivable that client code corrupts the memory in a way that causes 
>>mpz_get_str to corrupt other parts of the memory. But there is certainly 
>>grounds for suspicions...
>>
>>Two suggestions:
>>
>>(1) Run your program under a system like valgrind or purify or 
>>electricfence.
> 
> 
> Partial report for "valgrind --leak-check=yes ./myprogram <vargs>":
> ==6487==    Address 0x413CF75C is 0 bytes inside a block of size 3 alloc'd
> ==6487==    at 0x40029832: __builtin_vec_new (vg_replace_malloc.c:203)
> ==6487==    by 0x40029889: operator new[](unsigned) (vg_replace_malloc.c:216)
> ==6487== Invalid write of size 1
> ==6487==    at 0x4002275A: strcpy (mac_replace_strmem.c:174)
> ==6487== Invalid read of size 1
> ==6487==    at 0x403B3C17: strtok (in /lib/libc-2.3.2.so)
> ==6487==    Address 0x413D3653 is 0 bytes after a block of size 3 alloc'd
> ==6487==    at 0x40029832: __builtin_vec_new (vg_replace_malloc.c:203)
> ==6487==    by 0x40029889: operator new[](unsigned) (vg_replace_malloc.c:216)
> 
> And these are the errors only from GMP library functions.

Definitely not looking good. But this is C++ calling the C API of GMP 
directly. I have no experience with that (nor with the C++ wrappers!)

> 
> 
>>(2) Do you need a fully functional mpz_get_str or is it only for 
>>printing? If the latter, make your own but simply one returning an 
>>string of '?' of the correct length.
> 
> 
> I need to convert a bignumber into a string in a base x, and parse that 
> string during the program execution.

Suggestion: export the bignum in binary to a file, call a separate 
process to convert to string, recover the string in your 'normal' 
program. This should separate mpz_get_str from the rest of the 
processing. Then use valgrind separately on both processes. Yucky, I know...
> 
> 
>>(3) Do you allocate your own buffer or let gmp do it for you? If the 
>>latter, in the code of mpz_get_str (after all that's what OpenSource is 
>>for!), add a check that the allocated length is OK w.r.t. a length 
>>computed by yourself. (if your own buffer I trust you have made it big 
>>enough, i.e. mpz_sizeinbase (op, base) + 2).
> 
> 
> I used both versions, with my memory allocation, and the default 
> GMP allocation with the same weird results.
> 
> 1) char *buffer = new char[mpz_sizeinbase(bignumber,base)+2];
>    mpz_get_str (buffer, base, bignumber);

Does it work better with say 20 instead of 2?

> 
> 2) char *buffer = mpz_get_str(NULL, base, bignumber);

Do you use free() or delete on buffer? If GMP uses malloc maybe delete 
is not good... Just my 2Ec!

> 
> 
>>If you have already done all that, sorry, just trying to help.
>>
>>HaND,
>>
> 


-- 
Michel Bardiaux
Peaktime Belgium S.A.  Bd. du Souverain, 191  B-1160 Bruxelles
Tel : +32 2 790.29.41