From: Simon Marlow <simonmar@microsoft.com>
Date: Fri, 18 May 2007 12:25:05 +0000 (+0000)
Subject: FIX #767 (withMVar family have a bug)
X-Git-Url: http://git.megacz.com/?p=ghc-hetmet.git;a=commitdiff_plain;h=daa640e41e5bb964adc385509d97220b96d4ac5e;hp=1fb4c716c901f08b185439521f91f8cf552797c3

FIX #767 (withMVar family have a bug)
We never want to raise a StackOverflow exception inside
Control.Exception.block, because the user has no reasonable way of
handling it, and it invalidates some useful guarantees.
---

diff --git a/rts/Schedule.c b/rts/Schedule.c
index 6063fcd..f3d956a 100644
--- a/rts/Schedule.c
+++ b/rts/Schedule.c
@@ -2761,7 +2761,12 @@ threadStackOverflow(Capability *cap, StgTSO *tso)
   // while we are moving the TSO:
   lockClosure((StgClosure *)tso);
 
-  if (tso->stack_size >= tso->max_stack_size) {
+  if (tso->stack_size >= tso->max_stack_size && !(tso->flags & TSO_BLOCKEX)) {
+      // NB. never raise a StackOverflow exception if the thread is
+      // inside Control.Exceptino.block.  It is impractical to protect
+      // against stack overflow exceptions, since virtually anything
+      // can raise one (even 'catch'), so this is the only sensible
+      // thing to do here.  See bug #767.
 
       debugTrace(DEBUG_gc,
 		 "threadStackOverflow of TSO %ld (%p): stack too large (now %ld; max is %ld)",