PR# 13838 Missing critical section in `expop_helper' in except.c at chunk boundary
Problem Report Summary
Submitter: prestoat2000
Category: Runtime
Priority: Medium
Date: 2008/01/02
Class: Bug
Severity: Serious
Number: 13838
Release: 6.2.71689
Confidential: No
Status: Open
Responsible:
Environment: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.8.1.9) Gecko/20071111 Firefox/2.0.0.9
Solaris 10 on x86
Synopsis: Missing critical section in `expop_helper' in except.c at chunk boundary
Description
Based on code inspection only, it appears that there is a missing critical section in `expop_helper' in except.c, in the unusual case where we are at a chunk boundary. There are several macros in eif_macros.h that call `expop' (apparently without blocking signals) and `expop' calls `expop_helper'. In `expop_helper' we have /* Unusual case: top pointed to the arena of next chunk */ s= stk->st_cur = stk->st_cur->sk_prev; /* Go one chunk back */ CHECK("Not underflow", s); top = stk->st_end = s->sk_end; /* Set new end */ stk->st_top = --top; /* New top */ If signals aren't blocked and we get a signal where the CHECK is, then stk->st_cur will have been updated to point to previous chunk but stk->st_end stk->st_top won't have been updated, resulting in a messed up stack. The SIGBLOCK/SIGRESUME should also enclose the entire "else" clause, including the stack_truncate call, to avoid possible memory leaks. I'm guessing that the similar code for st_truncate in garcol.c doesn't have a problem because all callers block signals. Perhaps documentation for run-time routines needs to be extended to include information on whether signals must be blocked by the caller.
To Reproduce
Problem Report Interactions
Looks like `c_npop' in debug.c has the same problem, in the case where top == arena. Presumably, this code was copied from garcol.c and adapted.