I have managed to reproduce it a few times although it does seem to take a while. Moreover, it (perhaps not surprisingly) is quite dependent upon
#13970: Segmentation fault inside threadPaused -------------------------------------+------------------------------------- Reporter: albertov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by albertov): Replying to [comment:22 bgamari]: paralellism. I was unable to reproduce it in a reasonable amount of time on my dual-core, four-thread laptop. However, on my 4-core, eight-thread server I was able to reproduce it within ten minutes or so. How many cores does your test environment have? I'm testing on a 6-core, 12-thread machine. It is indeed hard to reproduce although it is no much more frequent. I've noticed that giving a large `-N` value to the RTS increases the odds. I'm testing with `-N30`. Have you tried increasing this value way over your number of cores? Another interesting thing is that without this [https://github.com/meteogrid/propag/blob/master/app/Main.hs#L69 pause] I was unable to reproduce the crash and noticed that a breakpoint I had set at `suspendComputation` was never being hit. Adding this pause causes `suspendComputation` to be called multiple times and eventually manifests the problem (when running outside gdb). Maybe playing with that pause helps increasing the odds in your environment? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13970#comment:23 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler