mpz_mul memory allocation bug

Daniel Kochmański dkochmanski at
Fri Jun 26 10:59:29 UTC 2015


Torbjörn Granlund writes:

Thank you for fast reply.
> Daniel Kochmański <dkochmanski at> writes:
>   I've encontered problem with GMP 6.0.0 when used with ECL (Embeddable
>   Common-Lisp). Memory is managed by bdwgc and gmp seems to allocate
>   memory somewhere, where it shouldn't, resulting in:
>     (SIGABRT) "Duplicate large block deallocation"
> OK. so GMP allocates memory where it shouldn't (whatever that means) and
> a LISP system as a result deallocates a memory area twice...  Your line
> of reasoning is not crystal clear.  :-)

I'm sorry if my message wasn't clear to you.
>   Problem is absent in GMP 4.2.1. After tracking problem, I've came to
>   conclusion, that it is caused by `mpn_fft_mul', which is called by
>   `mpn_sqr', being optimization for corner-case, when `mpz_mul' is called
>   with the same bignum as second and third argument.
>   Removing optimization "fixes" problem. `mpn_fft_mul' is called, when
>   size n isn't below `SQR_FFT_THRESHOLD', and comment:
>     /* The current FFT code allocates its own space.  That should probably
>        change.  */
>   might be a clue, that this is a place of problem.
> This comment does not say that we knowingly do something that is buggy.
> It is rather a suggestion for a code cleanup.
> If you have a self-contained tests case for GMP where it misbehaves,
> please report it to us.

I've realized, that it's not a bug afterall. Manual of GMP clearly
states in "Custom Allocation", that GMP may use allocated block to hold
pointers to other allocated blocks and this may cause problems with
conservative gc, what is a case here.
> You present report is nothing we can work with, I'm afraid.

Sorry for bothering.


Daniel Kochmański | Poznań, Poland
;; aka jackdaniel

"Be the change that you wish to see in the world." - Mahatma Gandhi

More information about the gmp-bugs mailing list