segfault/massive memory use when using Data.Bits.shiftL
Hi, The following either eats memory until killed or segfaults (I can't pin down a reason for the difference). Tested with GHC 6.2.2 and 6.4.20050212, with various different libgmp3s under various Redhat and Debian platforms, and WinXP. Prelude> :m +Data.Bits Prelude Data.Bits> 18446658724119492593 `shiftL` (-3586885994363551744) :: Integer Cheers, Ganesh
On Mon, Feb 28, 2005 at 02:55:56PM +0000, Ganesh Sittampalam wrote:
Hi,
The following either eats memory until killed or segfaults (I can't pin down a reason for the difference). Tested with GHC 6.2.2 and 6.4.20050212, with various different libgmp3s under various Redhat and Debian platforms, and WinXP.
Prelude> :m +Data.Bits Prelude Data.Bits> 18446658724119492593 `shiftL` (-3586885994363551744) :: Integer
Cheers,
Ganesh
shiftL for Integer is defined in fptools/libraries/base/Data/Bits.hs: class Num a => Bits a where shiftL :: a -> Int -> a x `shiftL` i = x `shift` i instance Bits Integer where shift x i | i >= 0 = x * 2^i | otherwise = x `div` 2^(-i) IOW, for y < 0: x `shiftL` y = x `shift` y = x `div` 2^(-y) and calculating, in your case, 2^3586885994363551744 is not something your computer is going to like... as it's probably a number which doesn't fit in our universe :) Still, a segfault might point at a bug, which I unfortunately won't be able to say much about. (Due to lack of knowledge & information.) Greetings, Remi -- Nobody can be exactly like me. Even I have trouble doing it.
On Mon, 28 Feb 2005, Remi Turk wrote:
On Mon, Feb 28, 2005 at 02:55:56PM +0000, Ganesh Sittampalam wrote:
Prelude> :m +Data.Bits Prelude Data.Bits> 18446658724119492593 `shiftL` (-3586885994363551744) :: Integer
and calculating, in your case, 2^3586885994363551744 is not something your computer is going to like... as it's probably a number which doesn't fit in our universe :)
Hmm, good point. I hadn't thought about the fact that the number of digits in the answer would be rather large...
Still, a segfault might point at a bug, which I unfortunately won't be able to say much about. (Due to lack of knowledge & information.)
My googling suggests that gmp is prone to segfaulting when things get too large for it, so I'll just chalk it up to that. I apologise for thinking this was a bug :-) Cheers, Ganesh
On Mon, Feb 28, 2005 at 10:59:32PM +0000, Ganesh Sittampalam wrote:
On Mon, 28 Feb 2005, Remi Turk wrote:
On Mon, Feb 28, 2005 at 02:55:56PM +0000, Ganesh Sittampalam wrote:
Prelude> :m +Data.Bits Prelude Data.Bits> 18446658724119492593 `shiftL` (-3586885994363551744) :: Integer
and calculating, in your case, 2^3586885994363551744 is not something your computer is going to like... as it's probably a number which doesn't fit in our universe :)
Hmm, good point. I hadn't thought about the fact that the number of digits in the answer would be rather large... Actually, the final answer will be 0: It's only the intermediate value that gets ridiculously large.
Still, a segfault might point at a bug, which I unfortunately won't be able to say much about. (Due to lack of knowledge & information.)
My googling suggests that gmp is prone to segfaulting when things get too large for it, so I'll just chalk it up to that.
I apologise for thinking this was a bug :-)
No need to apologize. Segfaults _are_ IMHO almost always bugs. And in this case too, though the fault isn't GHCs. Groeten, Remi
Cheers,
Ganesh
-- Nobody can be exactly like me. Even I have trouble doing it.
ganesh:
Hi,
The following either eats memory until killed or segfaults (I can't pin down a reason for the difference). Tested with GHC 6.2.2 and 6.4.20050212, with various different libgmp3s under various Redhat and Debian platforms, and WinXP.
Prelude> :m +Data.Bits Prelude Data.Bits> 18446658724119492593 `shiftL` (-3586885994363551744) :: Integer
Have you tried gmp-4? That's seems to be more stable. -- Don
participants (3)
-
dons＠cse.unsw.edu.au -
Ganesh Sittampalam -
Remi Turk