Fix for tailcall after newclosure
Bob Rogers
mighty peculiar things to happen if the sub had created any closures,
since those closures still refer to the just-freed context. Sometimes
(but not always) the context is reused for the next call; when this
happens, it seems to lead to a situation where the context's outer_ctx
field points back to itself. This causes Parrot_find_pad to loop
without bound.
The attached PIR code illustrates the problem, if anyone cares to
check it out, but it may not work in other builds. Sometimes, small
changes to distant parts of this code prevent the context from being
reused immediately, forestalling the bug. Commenting out the assignment
to $P55 is one such change. But if you do try it, you may also want to
apply the src/sub.c part of the attached patch, since this prevents
unbounded looping. Enabling the ignored code also makes it clear what
is happening.
The src/sub.c fix is intended just for debugging, though. The
patch's minimal change [1] to src/ops/core.ops actually fixes the
problem, at the risk of possibly leaking memory, since I still don't
fully understand the life cycle of contexts. However, I would argue
that any such leaks are independent problems that also need fixing. If
there are no objections to this part of the patch, I will commit it
tomorrow.
I didn't turn the test case into a proper regression test because I
didn't think it would be reliable enough. Maybe a check that is
intermittent is better than none at all? On the other hand, changes to
the context allocator could render it permanently useless . . .
-- Bob Rogers
http://rgrjr.dyndns.org/
[1] Minimal even according to Shannon: It changes only a single bit in
the codebase. All that work for one lousy bit . . .