On Sun, Oct 5, 2008 at 6:01 PM, Jared Updike
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