Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[PATCH] Restrict clear_eh to handlers in the current context

0 views
Skip to first unread message

Bob Rogers

unread,
Jan 6, 2006, 11:22:19 PM1/6/06
to p6i
If sub A pushes an error handler and then calls B, B can do a
'clear_eh' to get rid of A's handler. This seems to work until B
returns, at which point the control stack unwinding done by
RetContinuation destroys the rest of the stack looking for the missing
handler. The patch detects the problem in clear_eh, and signals a
real_exception.

Perhaps more controversially, it also makes it an error if clear_eh
finds something other than an exception at TOS. The original code did
nothing, which doesn't seem right. Error handlers are lexical features
of the source code, as are most other things on the control stack [1],
so finding a non-exception at TOS indicates a compiler bug (or a logic
error in hand-written PIR). Fortunately, this doesn't affect any of the
existing test cases -- so I added a new one to test regression.

You could also argue that the stack unwinding in
RetContinuation.invoke is broken. I tend to agree, but any such fix
would be superceded by an implemention of rezipping. This pop_exception
fix might also have to change, but probably only in detail.

-- Bob

[1] The sole exception is the return address used by the bsr/jsr and
ret instructions; these aren't bound to any lexical features of the
compiled language.

pop-exception-1.patch

Bob Rogers

unread,
Jan 13, 2006, 10:09:38 PM1/13/06
to p6i
From: Bob Rogers <rogers...@rgrjr.dyndns.org>
Date: Fri, 6 Jan 2006 23:22:19 -0500

If sub A pushes an error handler and then calls B, B can do a
'clear_eh' to get rid of A's handler. This seems to work until B
returns, at which point the control stack unwinding done by
RetContinuation destroys the rest of the stack looking for the missing
handler. The patch detects the problem in clear_eh, and signals a

real_exception . . .

You could also argue that the stack unwinding in
RetContinuation.invoke is broken. I tend to agree, but any such fix
would be superceded by an implemention of rezipping. This pop_exception
fix might also have to change, but probably only in detail.

Just in case this patch is still under consideration, I would like to
withdraw it; I think it's better to include it as part of the
rezipping-related control stack cleanup (the design rev for which is
still in progress). Unless somebody would like to see a patch with just
the test cases, both marked 'TODO'?

-- Bob Rogers
http://rgrjr.dyndns.org/

Jerry Gay

unread,
Jan 14, 2006, 11:45:50 AM1/14/06
to Bob Rogers, p6i
On 1/13/06, Bob Rogers <rogers...@rgrjr.dyndns.org> wrote:
> still in progress). Unless somebody would like to see a patch with just
> the test cases, both marked 'TODO'?
>
what's a 0.4.1 release without some TODO tests? the more the better.
~jerry

Bob Rogers

unread,
Jan 14, 2006, 1:55:58 PM1/14/06
to jerry gay, parr...@parrotcode.org, p6i
From: jerry gay <jerr...@gmail.com>
Date: Sat, 14 Jan 2006 08:45:50 -0800

Foolish question, I suppose. On the other hand, who knows when someone
might say, "Hey, that's not a bug; I need that!" . . .

-- Bob

clear-eh-context-todo.patch

Bob Rogers

unread,
Jan 14, 2006, 2:02:20 PM1/14/06
to jerry gay, parr...@parrotcode.org, p6i
Phooey; I should read what I write. This version changes the word
"sub" to "handler" in a comment, thereby causing it to make sense.

-- Bob

clear-eh-context-todo.patch

Bob Rogers

unread,
Jan 14, 2006, 1:56:31 PM1/14/06
to bugs-bi...@rt.perl.org
# New Ticket Created by Bob Rogers
# Please include the string: [perl #38236]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org/rt3/Ticket/Display.html?id=38236 >
clear-eh-context-todo.patch

Leopold Toetsch

unread,
Feb 6, 2006, 6:45:30 AM2/6/06
to Bob Rogers, p6i
Bob Rogers wrote:
> Phooey; I should read what I write. This version changes the word
> "sub" to "handler" in a comment, thereby causing it to make sense.

I've now implemented the proposed stricter clear_eh semantics. That is
* clear_eh can only clear exception handlers
* and only from the current context

Tests unTODOed and applied - r11444

Thanks,
leo

0 new messages