[GHC] #15571: Eager AP_STACK blackholing causes incorrect size info for sanity checks

[GHC]

#15571: Eager AP_STACK blackholing causes incorrect size info for sanity checks
-------------------------------------+-------------------------------------
        Reporter:  osa1              |                Owner:  (none)
            Type:  bug               |               Status:  patch
        Priority:  normal            |            Milestone:  8.6.1
       Component:  Runtime System    |              Version:  8.5
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #15508            |  Differential Rev(s):  Phab:D5165
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by Ömer Sinan Ağacan <omeragacan@…>):

 In [changeset:"66c17293648fd03a04aabfd807b3c8336e8f843a/ghc"
 66c17293/ghc]:
 {{{
 #!CommitTicketReference repository="ghc"
 revision="66c17293648fd03a04aabfd807b3c8336e8f843a"
 Fix slop zeroing for AP_STACK eager blackholes in debug build

 As #15571 reports, eager blackholing breaks sanity checks as we can't
 zero the payload when eagerly blackholing (because we'll be using the
 payload after blackholing), but by the time we blackhole a previously
 eagerly blackholed object (in `threadPaused()`) we don't have the
 correct size information for the object (because the object's type
 becomes BLACKHOLE when we eagerly blackhole it) so can't properly zero
 the slop.

 This problem can be solved for AP_STACK eager blackholing (which unlike
 eager blackholing in general, is not optional) by zeroing the payload
 after entering the stack. This patch implements this idea.

 Fixes #15571.

 Test Plan:
 Previously concprog001 when compiled and run with sanity checks

     ghc-stage2 Mult.hs -debug -rtsopts
     ./Mult +RTS -DS

 was failing with

     Mult: internal error: checkClosure: stack frame
         (GHC version 8.7.20180821 for x86_64_unknown_linux)
         Please report this as a GHC bug:
 http://www.haskell.org/ghc/reportabug

 thic patch fixes this panic. The test still panics, but it runs for a
 while
 before panicking (instead of directly panicking as before), and the new
 problem
 seems unrelated:

     Mult: internal error: ASSERTION FAILED: file rts/sm/Sanity.c, line 296
         (GHC version 8.7.20180919 for x86_64_unknown_linux)
         Please report this as a GHC bug:
 http://www.haskell.org/ghc/reportabug

 The new problem will be fixed in another diff.

 I also tried slow validate (which requires D5164): this does not introduce
 any
 new failures.

 Reviewers: simonmar, bgamari, erikd

 Reviewed By: simonmar

 Subscribers: rwbarton, carter

 GHC Trac Issues: #15571

 Differential Revision: https://phabricator.haskell.org/D5165
 }}}

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