nhc98 bignum div/mod gives wrong answers or segmentation faults

Hi! I'm in the first month of translating my brain from mira to hs, and seem to have come across an hnc98 bug: my app is the famous infinite-precision scientific math library - see http://freaknet.org/bignum - and while the hs version currently has no known bugs under hugs, when I compile with nhc98 it gives me pi as 3.157..... while sqrt(2) gives a couple of thousand correct decimal places and then segmentation faults. Other calculations run ok. The problem only seems to occur in code that uses the div/mod on Integers, so I'm assuming the problem is in that. I've trimmed down the sqrt2 example to a small source file which is attached and obligingly continues to work under hugs and dump core with nhc98. Unfortunately I don't have another architecture than Linux/x86 to try it on - would someone check whether it does the same on another system? I'm afraid that the wrong-answer of pi is rather hard to extract into a self-contained fragment as it uses the infinite-precision trig functions and they call in the rest of the world. The system is Slackware Linux 9.0 (GCC 3.2.2) on Intel Pentium 3 (Coppermine) with 128MB RAM. Hugs is hugs98 - November 2003 and nhc is nhc98-1.16 both compiled from source tarballs with no problems. I'm online every day or so if there are turther tests I can run to help out. Blessings Martin Guy

Martin Guy
I've trimmed down the sqrt2 example to a small source file which is attached and obligingly continues to work under hugs and dump core with nhc98.
Yes, I can reproduce the bug. I think it is likely due to nhc98 failing to check the internal representation size of large Integers correctly, causing some kind of uncaught heap overflow. Certainly, you can alter the number of digits calculated prior to the core dump by adjusting the heap size (e.g. with +RTS -H16M -RTS). Nasty, but at least you get the right answer before crashing!
I'm afraid that the wrong-answer of pi is rather hard to extract into a self-contained fragment as it uses the infinite-precision trig functions and they call in the rest of the world.
I suspect that the wrong value of pi is /not/ a manifestation of the same fault at all. If you want to send that code to me privately, I'm happy to investigate further. Regards, Malcolm
participants (2)
-
Malcolm Wallace
-
Martin Guy