Dave Rolsky
2006-10-14 20:51:21 UTC
Jon, in the 1.3x series, you changed the way the request object manages
the stack so we no longer use Perl's push and pop to add/remove items from
the stack. Instead, we manually manipulate track the current stack depth.
AFAICT, this was done to work around stack corruption when a component
exits via next(). Unfortunately, the side effect was to introduce a pretty
nasty leak, because what ended up happening is that stack frames were
never being removed from the stack, we just changed changed the value of
the "top of the stack" variable internally.
In 1.34, I introduced a change to pop the stack so that the frame (and
objects it references) actually get destroyed when the user expects. I
consider this a pretty serious bug, more serious than stack corruption
because of a bogus next.
Unfortunately, it seems like this popping introduced more bugs. The
existing code is really complicated, because it is in effect a
re-implementation of what Perl does internally for array handling.
When I revert the code back to just using Perl's push and pop, as we did
through 1.28, the tests pass except for the "exit via next" test.
Personally, I think that this is fine. The problem with next or last is
unfortunate, but Perl at least spits out a warning when you do it, so the
user gets some clue as to what's going on. It's not intractable to find
such bugs, and IMO it's not worth impossible gyrations to work around
this, especially when fundamentally the problem is with Perl itself. Using
next or last outside of loops should just be a no-op.
Anyway, I'd like to go ahead and revert the code that tries to manually
manage the stack and just use push and pop, like we used to, and then
release 1.3401 (or 1.35).
The real rub in all this is that I haven't been able to come up with a
nice isolated test of what I'm seeing in my app with 1.34 (a screwed up
stack where one of the frames is undef, for example). I'll keep trying to
come up with such a test.
-dave
/*===================================================
VegGuide.Org www.BookIRead.com
Your guide to all that's veg. My book blog
===================================================*/
the stack so we no longer use Perl's push and pop to add/remove items from
the stack. Instead, we manually manipulate track the current stack depth.
AFAICT, this was done to work around stack corruption when a component
exits via next(). Unfortunately, the side effect was to introduce a pretty
nasty leak, because what ended up happening is that stack frames were
never being removed from the stack, we just changed changed the value of
the "top of the stack" variable internally.
In 1.34, I introduced a change to pop the stack so that the frame (and
objects it references) actually get destroyed when the user expects. I
consider this a pretty serious bug, more serious than stack corruption
because of a bogus next.
Unfortunately, it seems like this popping introduced more bugs. The
existing code is really complicated, because it is in effect a
re-implementation of what Perl does internally for array handling.
When I revert the code back to just using Perl's push and pop, as we did
through 1.28, the tests pass except for the "exit via next" test.
Personally, I think that this is fine. The problem with next or last is
unfortunate, but Perl at least spits out a warning when you do it, so the
user gets some clue as to what's going on. It's not intractable to find
such bugs, and IMO it's not worth impossible gyrations to work around
this, especially when fundamentally the problem is with Perl itself. Using
next or last outside of loops should just be a no-op.
Anyway, I'd like to go ahead and revert the code that tries to manually
manage the stack and just use push and pop, like we used to, and then
release 1.3401 (or 1.35).
The real rub in all this is that I haven't been able to come up with a
nice isolated test of what I'm seeing in my app with 1.34 (a screwed up
stack where one of the frames is undef, for example). I'll keep trying to
come up with such a test.
-dave
/*===================================================
VegGuide.Org www.BookIRead.com
Your guide to all that's veg. My book blog
===================================================*/