[GHC] #13916: Optimizations create run time seg faults

[GHC]

#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