#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