From daa640e41e5bb964adc385509d97220b96d4ac5e Mon Sep 17 00:00:00 2001 From: Simon Marlow Date: Fri, 18 May 2007 12:25:05 +0000 Subject: [PATCH] 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. --- rts/Schedule.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) 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)", -- 1.7.10.4