Branch: refs/heads/davem/tied_method_realav
Home: https://github.com/Perl/perl5
Commit: 9d0763202f9b83efe08b11749b3dc47ac27b0b6c
https://github.com/Perl/perl5/commit/9d0763202f9b83efe08b11749b3dc47ac27b0b6c
Author: David Mitchell <da...@iabyn.com>
Date: 2024-03-17 (Sun, 17 Mar 2024)
Changed paths:
M pp_sys.c
Log Message:
-----------
Perl_tied_method(): *conditionally* use RC stack
Fixes GH #21784.
Perl_tied_method() is used to call tied methods for filehandles. One of
its actions is to push a new stackinfo (and hence a new argument stack)
to run the method under. When the method returns, any returned values
are copied back to to original stack and the stackinfo popped. But
stackinfos (and the AV pointed to by si_stack) aren't freed at that
point; they are kept around until global destruction, in case they're
needed again.
Before this commit, Perl_tied_method() was incorrectly *always* making
the new stack AvREAL: this should in fact be done only on PERL_RC_STACK
builds.
The effect of this was that, on non-PERL_RC_STACK builds, any temp SVs
created as the return value(s) from the method call, would be left on
the abandoned stack, while the SVs themselves have long since been freed.
Normally this doesn't matter much - the array will be finally emptied
only during global destruction, which doesn't care if an already-freed
SV is attempted to be freed again.
But this was causing Coro to fail, because it maintains a stackinfo
chain per green thread, and manages and frees them itself, so they can
end up being freed before global destruction, triggering an 'Attempt to
free unreferenced scalar' warning.
For completeness, this commit now also resets PL_stack_sp to
PL_stack_base before abandoning the stack, so that that on PERL_RC_STACK
builds, there's no chance of the copied return value SVs being
double-counted later on,
To unsubscribe from these emails, change your notification settings at
https://github.com/Perl/perl5/settings/notifications
