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

[GHC]

#15038: Memory Corruption (strange closure type)
-------------------------------------+-------------------------------------
        Reporter:  andrewthad        |                Owner:  (none)
            Type:  bug               |               Status:  patch
        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):  Phab:D4652
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by simonpj):

 Aha. Concerning other error-ids, like `patErrorId`, look at this, in
 `MkCore`:
 {{{
 mkRuntimeErrorId name
  = mkVanillaGlobalWithInfo name runtimeErrorTy bottoming_info
  where
     bottoming_info = vanillaIdInfo `setStrictnessInfo`    strict_sig
                                    `setArityInfo`         1
                         -- Make arity and strictness agree

         -- Do *not* mark them as NoCafRefs, because they can indeed have
         -- CAF refs.  For example, pAT_ERROR_ID calls GHC.Err.untangle,
         -- which has some CAFs
         -- In due course we may arrange that these error-y things are
         -- regarded by the GC as permanently live, in which case we
         -- can give them NoCaf info.  As it is, any function that calls
         -- any pc_bottoming_Id will itself have CafRefs, which bloats
         -- SRTs.
 }}}
 This came from a commit back in 2002!
 {{{
 commit 33ce2a14d1220bd3b9f00e8d461b8f9ef31ee411
 Author: simonpj <unknown>
 Date:   Fri Jun 28 14:06:54 2002 +0000

     [project @ 2002-06-28 14:06:52 by simonpj]
     -----------------------------------
         Fix the CAF info field of error Ids
         -----------------------------------

     A bizarre bug.   In MkId, we build the Id for various error-y
     Ids (like pAT_ERROR_ID) that we grab out of thin air in various
     places (like the desugarer).  They were marked as not referring
     to any CAFs, but this was a lie!  In fact, they refer to 'untangle'
     (see GHC.Err) and thence to a CAF.

     Result: GC crash under very obscure circumstances.  (Rob's optimistic
     evaluator tickled it.)

     Solution: give them more conservative IdInfo.

     Two other better solutions to think about:

     * Don't grab them out of thin air; instead get them from
       an interface file.

     * Treat them as always-live (requires mod to garbage collector)
       so they don't need to be mentioned in SRTs at all
 }}}
 So even if we fixed #15113, that would not help with `patErrorId` etc,
 becuase they
 are wired-in Ids, built with `mkRuntimeErrorId`, and hence
 (conservatively)
 marked `MayHaveCafRefs`.

 What to do? I hate this special treatment of `aBSENT_ERROR_ID` etc.  Let's
 instead:

 * Add `Note [The CAF-ness of error Ids]` explaining all this.

 * Make all the error ids (both `aBSENT_ERROR_ID` and `mkRuntimeErrorId`
 start with `errorIdInfo`

 * Define `errorIdInfo = noCafInfo`, pointing to `Note [The CAF-ness of
 error Ids]`, which says that we can mark them no-CAF because (and only
 because) we add them the to the Stable Pointer Table; see `Note
 [StableGcRoots]` in `RtsStartup.c`.

 * Add all the wired-in error-ids to the list in `RtsStartup.c`.  And make
 sure that
   the `MkCore.errorIds` list also points to the Note.

 Now all the error Ids will be non-CAFy, we'll get smaller SRTs etc, which
 is good.  And there will be no special treatment of the unboxed-sum
 business.  (But you might want a Note in the unarise transform to explain
 that adding a reference to absent-error-id doesn't change CAFyness.)

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