[armedbear-devel] Problems with compiled PROGV?

[Erik Huelsmann]

Hi Mark,

On Fri, Mar 5, 2010 at 8:57 AM, Mark Evenson <evenson at panix.com> wrote:
> In analyzing the [bug with CL-JSON][1], I think the culprit lies in improper compilation of PROGV forms, although I have yet to come up with a simple example factored out of the CL-JSON codebase.  Reading last night's #abcl logs, I saw that Erik made a comment about problems with PROGV as well, without specifics.  Thinking that if I had other examples of how PROGV misbehaves it might shed some light on my problems, I'd like to ask for details about other misbehavior of compiled PROGV forms however scant.  Cases that are reproducible would be most welcome.


Well, the problem is that I looked at the implementation of
interpreted PROGV and then at what the compiler generates. The
structure of the code looks the same: interpreted uses a try/finally
block and that's what compiled does too.

The difference that I can see is in the way the compiler and the
interpreter do local transfer of control (like RETURN-FROM, which
CL-JSON uses): the interpreter uses the same means as for non-local:
raising a Java exception (and thus always triggering the finally). The
compiler restores a specific dynamic environment and uses a JMP
instruction to jump out of the PROGV block.

However, this mechanism is used for other blocks which binding
specials too and I'm not aware of issues with those. This is why I
would like to know more specific reproduction recipies, because the
cl-json code is a bit too complex to test this entirely.

One thing to try would be to add (progv-node-p block) to the
BLOCK-REQUIRES-NON-LOCAL-EXIT-P function, making the compiler generate
non-local exits (exceptions) just like the interpreter. If that fixes
it: we have a problem with the dyn-env determination or some other
part of dyn-env management with local transfer of control blocks.

HTH,

Erik.