#13916: Optimizations create run time seg faults -------------------------------------+------------------------------------- Reporter: newthin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (CodeGen) | Keywords: optimization | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In the attached program, when compiling `ghc main.hs -O2`, the program immediately segfaults on run. When compiled with `ghc main.hs`, however, the program runs fine. Indeed, in our full code base it seems like even no flag is not enough, and I must explicitly begin the Bracket module with `{-# OPTIONS_GHC -O0 #-}` -- however, that may be due to stack or some other build tool. The main logic which fails is in Bracket.hs, which provides an api to convert bracket-like environment handlers (those with open/close capabilities) to caches which you can run concurrent actions against. The API allows two types of limit on the number of concurrent environments - a `Lax` limit, which will spin up additional connections if none are available, and a `Hard` limit, which caps the environment count. This seems like a detail, but if I remove the `Lax` option (as in BracketOneType), the bug goes away. With both options present, both options manifest the bug. The main.hs module is just a toy program aimed at this api, where we write 1000 lines split to arbitrary files (in a `__dir` specified on the top line - set to tmp). None of this code is important - the actual use case (which fails) is handling multiple concurrent connections to a database. The other programs (mainList, mainOneModule, and mainOneType) all appear to run correctly, and represent my attempts to create minimal cases. In particular, these respectively replace Vector with List, move all code into a single module, and get rid of the multiple options for cache types. The modules should all be the same modulo imports (or inlining) of different `Bracket` modules. I have replicated the bug on Linux, Windows, and Windows Creator Update, all with their respective versions of GHC-8.0.2. The code fails for at least vector-0.11.0.0 and vector-0.12.0.1. NB: There are times with the database access example where, worse than crashing, the program will simply return bad results. I think this might have to do with the laziness of `withEnv`, and our production version uses NFData to deepseq arguments before returning the environment to the cache - that was omitted in this test case for simplicity's sake. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13916 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler