Hi Mark, On Fri, Mar 5, 2010 at 8:57 AM, Mark Evenson <evenson@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.