On Sun, Oct 5, 2008 at 6:01 PM, Jared Updike <[EMAIL PROTECTED]> 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 _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
