[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