#3940: Propagate bug fix into new code generator
---------------------------------+------------------------------------------
Reporter: simonpj | Owner:
Type: bug | Status: new
Priority: normal | Milestone: 6.14 branch
Component: Compiler | Version:
Keywords: | Difficulty:
Os: Unknown/Multiple | Testcase:
Architecture: Unknown/Multiple | Failure: None/Unknown
---------------------------------+------------------------------------------
We must not forget to propagate this fix into the new code generator
pipeline:
{{{
Thu Mar 25 04:03:28 PDT 2010 Simon Marlow <[email protected]>
* do_checks: do not set HpAlloc if the stack check fails
This fixes a very rare heap corruption bug, whereby
- a context switch is requested, which sets HpLim to zero
(contextSwitchCapability(), called by the timer signal or
another Capability).
- simultaneously a stack check fails, in a code fragment that has
both a stack and a heap check.
The RTS then assumes that a heap-check failure has occurred and
subtracts HpAlloc from Hp, although in fact it was a stack-check
failure and retreating Hp will overwrite valid heap objects. The bug
is that HpAlloc should only be set when Hp has been incremented by the
heap check. See comments in rts/HeapStackCheck.cmm for more details.
This bug is probably incredibly rare in practice, but I happened to be
working on a test that triggers it reliably:
concurrent/should_run/throwto001, compiled with -O -threaded, args 30
300 +RTS -N2, run repeatedly in a loop.
M ./compiler/codeGen/CgHeapery.lhs -6 +16
}}}
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3940>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
