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

GHC ghc-devs at haskell.org
Sat Apr 28 11:01:05 UTC 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:                    |
-------------------------------------+-------------------------------------
Changes (by osa1):

 * cc: simonpj, bgamari (added)
 * priority:  normal => highest


Comment:

 Finally found the problem. In summary; in unarise we introduce
 `absentError` calls for unboxed sum slots that are not supposed to be used
 and `absentError` id (`aBSENT_ERROR_ID`) is marked as CAFFY. Now suppose
 we had a top-level definition that is not CAFFY but uses unboxed sums.
 `TidyPgm` thinks that it's not CAFFY. But in unarise we make it CAFFY.
 This causes mismatch between the CAF info recorded in the binder id for
 this top-level definition and the actual RHS. The code that generates
 closure layout doesn't add a static_link field, but the code that
 generates the info table generates a SRT and SRT bitmap.

 Some potential solutions:

 - Why is `absentError` marked as CAF? I think error ids are conservatively
 marked as `MayHaveCafRefs` but perhaps it's fine to not mark `absentError`
 as `MayHaveCafRefs`. (I implemented this and it fixed the bug)

 - Update CAFFY-ness of ids in unarise if we introduce `absentError`
 (haven't tried this yet)

 - Something else?

 Any ideas? Ping @simonpj @bgamari

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


More information about the ghc-tickets mailing list