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

[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?"

  Jared.

On 10/5/08, Alexander Dunlap <alexander.dunlap at gmail.com> wrote:
> On Sun, Oct 5, 2008 at 5:38 PM, Chris Mears <chris at cmears.id.au> wrote:
>  > "Jared Updike" <jupdike at gmail.com> 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 at 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
>