[GHC] #14521: Infinite loop at runtime when either : a given function is not marked INLINE, or functions are stored in strict field

[GHC]

#14521: Infinite loop at runtime when either : a given function is not marked
INLINE, or functions are stored in strict field
-------------------------------------+-------------------------------------
        Reporter:  OlivierSohn       |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:  8.2.3
       Component:  Compiler          |              Version:  8.0.2
      Resolution:                    |             Keywords:
Operating System:  MacOS X           |         Architecture:
 Type of failure:  Incorrect result  |  Unknown/Multiple
  at runtime                         |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------
Description changed by OlivierSohn:

Old description:

> Hello,
>
> in https://github.com/OlivierSohn/hamazed/issues/1 I describe the
> following issue:
>
> When compiling on OSX with optimizations (`stack clean && stack build`
> using resolver `lts-9.12` (ghc 8.0.2)), the program loops infinitely
> (400% CPU, and execution is blocked) when an animation is triggered in
> the game. When compiling without optimizations, there is not this bug.
>
> The bug is visible at this commit :
> https://github.com/OlivierSohn/hamazed/commit/9f25223ef0502f91cd9633654bdb172f714c3920
> (to reproduce, shoot at a number in the game)
>
> I originally fixed this behaviour by pragma-declaring INLINE the function
> `Animation.animate' (this function consumes an Animator record) :
> https://github.com/OlivierSohn/hamazed/commit/597619bb14974d2bbacfb284a9e276a7cf2d2f52
>
> And later, I found that another way to fix the behaviour is to remove the
> strict annotation on the fields of the record "Animator", ie changing
>
> {{{
> data Animator a = Animator {
>     _animatorPure :: !(Iteration -> (Coords -> Location) -> Tree -> Tree)
>   , _animatorIO   :: !(Tree -> StepType -> Animation -> (Coords ->
> Location) -> RenderState -> IO (Maybe Animation))
>   , _animatorColorFromFrame :: !(Frame -> Color8Code)
> }
> }}}
>
> to:
>
> {{{
> data Animator a = Animator {
>     _animatorPure :: (Iteration -> (Coords -> Location) -> Tree -> Tree)
>   , _animatorIO   :: (Tree -> StepType -> Animation -> (Coords ->
> Location) -> RenderState -> IO (Maybe Animation))
>   , _animatorColorFromFrame :: (Frame -> Color8Code)
> }
> }}}
>
> Could this be a compiler bug?
>
> The code is available at https://github.com/OlivierSohn/hamazed
>
> I could try to create another program that reproduces the issue more
> easily (without having to play the game), just let me know if you need
> it.
>
> Also, here is my stack version if it matters:
> {{{
> stack version: `1.3.2, Git revision
> 3f675146590da4f3edf768b89355f798229da2a5 (4395 commits) x86_64
> hpack-0.15.0`
> }}}
>
> Thank you,
> Olivier

New description:

 Hello,

 in https://github.com/OlivierSohn/hamazed/issues/1 I describe the
 following issue:

 When compiling on OSX with optimizations (`stack clean && stack build`
 using resolver `lts-9.12` (ghc 8.0.2)), the program loops infinitely (400%
 CPU, and execution is blocked) when an animation is triggered in the game.
 When compiling without optimizations, there is not this bug.

 The bug is visible in the full game at this commit :
 https://github.com/OlivierSohn/hamazed/commit/9f25223ef0502f91cd9633654bdb172f714c3920
 (to reproduce, shoot at a number in the game)

 And this commit shows a program with minimal code to reproduce the issue :
 https://github.com/OlivierSohn/hamazed/commit/30b0f703565a4150d686a36a4dfe9d36ce5989f1

 The expected output of the program is

 {{{
 Before rendering animations
 animation is rendered
 After rendering animations
 }}}

 What I observe is

 {{{
 Before rendering animations
 }}}

 I found several ways to circumvent the problem, wrote them in the code to
 help debugging.

 Also, here is my stack version if it matters:
 {{{
 stack version: `1.3.2, Git revision
 3f675146590da4f3edf768b89355f798229da2a5 (4395 commits) x86_64
 hpack-0.15.0`
 }}}

 Thank you,
 Olivier

--

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