#9647: allocation of 10790760 bytes too large -------------------------------------+------------------------------------- Reporter: mirko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: run time Operating System: Windows | insufficient memory Type of failure: Incorrect | Architecture: x86_64 (amd64) warning at compile-time | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Please edit your description to remove extraneous information about the bug reporting process—you can report a separate bug against the TRAC component in the "component" drop-down if you like. I don't know much about GHC's handling of huge Integers, but I believe it uses GMP, which can barf when they're ''too'' large, which yours may very well be. GMP also appears to lack any sort of graceful error handling mechanism, and as I understand it there are dependency issues preventing GHC's code from catching the hardware faults GMP throws. Specifically, I believe the code implementing `Integer` is very low down in the dependency stack, so it doesn't have access to fancy error-management mechanisms. GHC handles this partially by performing some sanity checks before handing the calculation off, but this sanity checking isn't enough to prevent crashes resulting from calculations reaching overly-large numbers. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9647#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler