[Haskell-cafe] MPFR / FFI - Nefarious (Simple?) bug
Judah Jacobson
judah.jacobson at gmail.com
Sun Oct 5 23:45:35 EDT 2008
On Sun, Oct 5, 2008 at 6:01 PM, Jared Updike <jupdike at gmail.com> wrote:
> Thanks for trying out my code. I'm glad it's not particular to my system.
>
> I suspected it had to do with the GHC RTS monkeying around with the
> heap (lower precisions print more iterations and maybe aren't moving
> through the heap as fast?) but I think when I added a statement to
> print out the hex address for each Ptr MPFR that those pointers (to
> 'one') in particular weren't getting moved. Likely the stuff living in
> the heap, pointed at in the MPFR struct, specifically the pointer to
> the limbs (the mantissa or actual digits of the number) are getting
> kludged.. I don't really understand why this is the case when I don't
> think I'm allocating a lot of the heap or anything, just printing the
> same number over and over... Is there a space leak somewhere? (I can
> also verify that mpf_new_mpfr is only getting called once per program
> run by appending to a file each time it gets called). How do I tell
> GHC "leave this mess and anything in the C heap completely alone?"
>
Usually, you can expect GHC to leave the C heap alone. The exception,
unfortunately, is GMP (which is used by MPFR). See the following
ticket:
http://hackage.haskell.org/trac/ghc/ticket/311
I'm guessing that's the cause of the corruption. The relevant note
from that ticket:
> It's a known problem that you can't use GMP via the FFI from
> your Haskell code in GHC, or use a C library that internally
> uses GMP. We should really use a private version of GMP
> with function names that don't overlap, or better still
> replace GMP altogether.
The comment in that ticket from Benedict Huber details some possible
workarounds.
Best,
-Judah
More information about the Haskell-Cafe
mailing list