#10282: Segfault when calling show on an Integer of a certain size -------------------------------------------+------------------------------- Reporter: gelisam | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------------+------------------------------- You're not going to believe this. {{{ $ ghc -e 'let k = show (10^184000) in k == k' True $ ghc -e 'let k = show (10^187000) in k == k' True $ ghc -e 'let k = show (10^186000) in k == k' Bus error }}} That's right: there is a problem which affects Integer values which are 186000 digits long, but which does not affect values which are 187000 digits long. So {{{10^184000}}} works fine, {{{10^187000}}} works fine, but {{{10^186000}}} doesn't. What about {{{10^185000}}}? Well, it depends on your version of GHC. And on chance. GHC 7.10.0.20150123 is always happy with {{{10^185000}}}, but GHC 7.8.3 crashes about two-thirds of the time: {{{ $ ghc -e 'let k = show (10^185000) in k == k' True Segmentation fault }}} And it's a different kind of crash, too! A segmentation fault instead of a "bus error". I have tried all the lengths in {{{[1000,2000,..,100000]}}}, and some lengths are fine, some lengths have a bus error, and some lengths segfault. The most helpful lengths I've encountered give an error message about malloc: {{{ $ ghc -e 'let k = show (10^264000) in k == k' True ghc(72417,0x107081000) malloc: *** error for object 0x107300000: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug Abort trap }}} Sometimes it gives a slightly different error message: {{{ $ ghc -e 'let k = show (10^264000) in k == k' ghc(72453,0x107381000) malloc: *** error for object 0x107200128: incorrect checksum for freed object - object was probably modified after being freed. *** set a breakpoint in malloc_error_break to debug Abort trap }}} Anyway, a lot more people posted their results in the following reddit thread, without realizing that the problem had to do with the length: http://www.reddit.com/r/haskell/comments/31yajd/can_you_explain_this/ So far, only folks on OS X have managed to reproduce the problem. The problem occurs with {{{ghci}}}, {{{runhaskell}}} and {{{ghc -e}}}, but not with compiled binaries. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10282 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler