[GHC] #15038: Memory Corruption (strange closure type)

[GHC]

#15038: Memory Corruption (strange closure type)
-------------------------------------+-------------------------------------
        Reporter:  andrewthad        |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  highest           |            Milestone:  8.6.1
       Component:  Compiler          |              Version:  8.4.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  Runtime crash     |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #9718             |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by andrewthad):

 Ömer, thanks for the excellent sleuthing and the very clear explanation of
 what had gone awry.  It sounds like the crash I have been experiencing
 will be fixed in GHC 8.6 (and that someone may resolve the longstanding
 #9718).  What I don’t fully grasp is the set of circumstances under which
 this error manifests itself.  Based on my reading of the explanation, it
 seems like  this would happen any time there  was a pattern match on an
 unboxed sum in which none  of the cases referenced a CAF.  But that
 doesn’t seem right, because that would mean that this error would happen
 all the time.  The reason I am interested in understanding this is because
 I would like to know if there is a  subset of programs in which unboxed
 sums  can safely be used.  Or,  as a library author, is it  currently
 impossible to use unboxed sums in such a way that the end user cannot
 induce the failure case?

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