[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:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by bgamari):

 Replying to [comment:19 osa1]:
 > STG for `absentError`:
 ...
 >
 > Apparently this is CAFFY (othewise we'd see `Caf=NoCafRefs`).
 >

 Right, that's what I suspected.

 > I also realized that unarise uses `absentError` wrong: `absentError`
 expects an `Addr#` argument (for a string that represents the "absent"
 argument) but unarise just uses `absentError` without an argument. So
 there's also a type error.
 >
 Yikes! It seems like this is one case that the old STG lint type-checker
 likely could have caught. Oh well.

 > Applying `absentError` to an argument in unarise would mean let bindings
 (heap allocation) so perhaps we should use something else for unused
 pointer location in unboxed sums. (IIRC when we first used `absentError`
 it wasn't taking an argument)
 >
 > If the id we'll use instead of `absentError` is not CAFFY then this
 problem will disappear.

 Yes, this seems like the shortest path to solving this. Introduce a
 variant of `absentError` that throws a less helpful error message but
 requires no allocation and isn't caffy.

 > However I wonder if we could somehow implement a check that ensures we
 won't make things more caffy after `TidyPgm` in the future.

 The whole interaction between CorePrep, CoreTidy, and caffyness is quite
 unfortunate. It would be better if CorePrep and CoreTidy were less coupled
 in this regard. I thought there was a ticket discussing this, but I'm
 having trouble finding it at the moment.

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