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

28 Apr 2018

      #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 osa1):

 STG for `absentError`:

 {{{
 lvl_r3wv :: GHC.Prim.Addr#
 [GblId, Caf=NoCafRefs, Unf=OtherCon []] =
     "Oops!  Entered absent arg "#;

 Control.Exception.Base.absentError :: forall a. GHC.Prim.Addr# -> a
 [GblId, Arity=1, Str=x, Unf=OtherCon []] =
     [] \r [s_s3BA]
         let {
           sat_s3BB [Occ=Once] :: [GHC.Types.Char]
           [LclId] =
               [s_s3BA] \u [] GHC.CString.unpackCStringUtf8# s_s3BA;
         } in
           case
               GHC.CString.unpackAppendCString# lvl_r3wv sat_s3BB
           of
           sat_s3BC
           { __DEFAULT -> GHC.Err.errorWithoutStackTrace sat_s3BC;
           };
 }}}

 Apparently this is CAFFY (othewise we'd see `Caf=NoCafRefs`).

 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.

 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. However I wonder if we could somehow implement a
 check that ensures we won't make things more caffy after `TidyPgm` in the
 future.

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