Re: [Haskell-cafe] MPFR / FFI - Nefarious (Simple?) bug

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?" Jared. On 10/5/08, Alexander Dunlap wrote:

On Sun, Oct 5, 2008 at 5:38 PM, Chris Mears wrote:

...

"Jared Updike" writes:

...

Can someone else verify if this is a Mac/BSD only problem by compiling and running my code? (Does the C executable"works" work? Does the Haskell executable "noworks" not work?) Can anyone on Linux and Windows attempt to compile/run and see if you can get the same results?

I can't help you fix the problem, but can confirm that it behaves as you describe on my Linux system. The program "works" produces correct output, but noworks gives:

================================================== [...] 290 1.00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 291 1.00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000315821571076304370386829039486164636536120569099678825575157477354990710405658927062619547595122867857873765133026050519075772712996650488675128428778696175272153632855303857710094714398932056909218681833163883482512398576534211955878126971368731378321605715030861892325510831739618679352919703855747262870175016933079782350322237289103929997053812694251557912158924211585973481445271933347978517620 292 [...] 384 1.00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000315821571076304370386829039486164636536120569099678825575157477354990710405658927062619547595122867857873765133026050519075772712996650488675128428778696175272153632855303857710094714398932056909218681833163883482512398576534211955878126971368731378321605715030861892325510831739618679352919703855747262870175016933079782350322237289103929997053812694251557912158924211585973481445271933347978517620 385 1.00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000315821571076304370386829039486164636536120569099678825575157477354990710405658927062619547595122867857873765133026050519075772712996650488675128428778696175272153632855303857710094714398932056909218681833163883482512398576534211955878126971368731378321605715030861892281684860507747503219323326708248193093246881500522519352192987169395899758472958160241015525770811984166890239749344848735134541218 386 ../get_str.c:149: assertion failed: size_s1 >= m Aborted ==================================================

All the values from 291-384 are the same, but 385 is slightly different.

...

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

My results (from Linux i686) are slightly different. I am getting

[...] 287 1.00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 288

get_str.c:149: assertion failed: size_s1 >= m Aborted

i.e. I never get the random numbers; they are all zeroes but it aborts after 287 successful repetitions.

Changing the default heap size (with +RTS -H<size>) changes how far it runs (running with -H32M let it go past 8000 repetitions), so this might be a garbage-collection issue.

Hope that is some help to you.

Alex