On Wed, Jul 11, 2007 at 10:55:28AM -0700, Bryan O'Sullivan wrote:
Richard Kelsall wrote:
It seems to randomly claim to have successfully created huge sizes of array.
This may be outside of Haskell's control, as you're not actually touching the memory you allocate. I wouldn't be surprised if the underlying page allocation is succeeding by virtue of the OS being willing to overcommit resources that may not actually be used. (This would be normal behaviour on Linux, for example.) In such a case, the Haskell runtime may not receive an error until you try to actually touch the data.
Not a sufficient explanation - you can only allocate addrssable memory, even on Linux I can't allocate more than 3GB of storage.
You can get GHC to fix an upper limit on the heap size it will try to use, by passing "+RTS -M768m -RTS" to your compiled program on the command line. That should cause your program to crash more reliably.
That still won't work because GHC trims the array size to an Int interally, and trims the byte count to an Int again before passing it to the OS. stefan@stefans:~$ ghci Loading package base ... linking ... done. ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.7.20070612, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Prelude> :m + Data.Array.Unboxed Prelude Data.Array.Unboxed> array (0,maxBound :: Int) [(-2, 42::Int)] :: UArray Int Int array Segmentation fault stefan@stefans:~$ http://hackage.haskell.org/trac/ghc/ticket/229 (yes, that's a 3 digit bug number) Stefan