#15571: Eager AP_STACK blackholing causes incorrect size info for sanity checks -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): We discussed this. Simon is right in comment:1 that this is problem with eager blackholing in general. However, eager blackholing is optional, so if you're working on the RTS and you need sanity checks can always not use it (which is the default). The problem with AP_STACK eager blackholing is more serious as it can't be disabled (expect perhaps in non-threaded runtime?) Anyways, we came up with this plan: - Implement a new stack frame AP_STACK_EAGER_BLACKHOLE which is exactly like the EAGER_BLACKHOLE but indicates that the object that became an eager blackhole was an AP_STACK. - (Only in debug runtime) Allocate one more word when allocating an AP_STACK and record its size. Note that this is only possible because we only allocate AP_STACKs in runtime (and not in generated code). - When eagerly blackholing an AP_STACK use AP_STACK_EAGER_BLACKHOLE instead of EAGER_BLACKHOLE and record the AP_STACK's size. - When we actually BLACKHOLE the AP_STACK_EAGER_BLACKHOLE in `threadPaused` we look at the size of the object and we can correctly return the `AP_STACK` size in `closure_sizeW()` because we recorded it in step (2). Simon, did I get this right? One thing I'm not sure (and forgot to ask at the meeting) is (3) in the bug report. I don't know if we're supposed to zero the slop when blackholing an AP_STACK eager blackhole in `threadPaused`. We enter the AP_STACK right after eagerly blackholing it, but I'm not sure if we can call `threadPaused` before being done with the stack. Can you comment on this? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15571#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler