Re: [GHC] #13615: Nondeterminism in ‘pure’ function w/ parallel evaluation & memo combinators

[GHC]

#13615: Nondeterminism in ‘pure’ function w/ parallel evaluation & memo combinators
-------------------------------------+-------------------------------------
        Reporter:  pacak             |                Owner:  bgamari
            Type:  bug               |               Status:  closed
        Priority:  highest           |            Milestone:  8.2.1
       Component:  Compiler          |              Version:  7.10.3
      Resolution:  fixed             |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Incorrect result  |  Unknown/Multiple
  at runtime                         |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):  Phab:D3695
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by Ben Gamari <ben@…>):

 In [changeset:"c940e3b92f4527ca59fcae93f36c869de3e7ccb9/ghc" c940e3b/ghc]:
 {{{
 #!CommitTicketReference repository="ghc"
 revision="c940e3b92f4527ca59fcae93f36c869de3e7ccb9"
 dmdAnal: Ensure that ExnStr flag isn't dropped inappropriately

 This fixes #13977 and consequently #13615. Here an optimization in the
 demand analyser was too liberal, causing us to drop the ExnStr flag and
 consequently resulting in incorrect demand signatures. This manifested
 as a segmentation fault in #13615 as we incorrectly concluded that an
 application of catchRetry# would bottom.

 Specifically, we had

     orElse' :: STM a -> STM a -> STM a
     orElse' x = catchRetry# x y
       where y = {- some action -}

 Where the catchRetry# primop places a demand of <xC(S),1*C1(U)> on its
 first argument. However, due to #13977 the demand analyser would assign
 a demand of <C(S),1*C1(U)> on the first argument of orElse'. Note the
 missing `x`.

     case orElse' bottomingAction anotherAction of { x -> Just x }

 being transformed to,

     case orElse' bottomingAction anotherAction of {}

 by the simplifier. This would naturally blow up when orElse' returned at
 runtime, causing the segmentation fault described in #13615.

 Test Plan: Validate, perhaps add a testcase

 Reviewers: austin, simonpj

 Reviewed By: simonpj

 Subscribers: rwbarton, thomie

 GHC Trac Issues: #13977, #13615

 Differential Revision: https://phabricator.haskell.org/D3756
 }}}

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13615#comment:53>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler