Branch: refs/heads/davem/tied_method_realav Home: https://github.com/Perl/perl5 Commit: 150bc24c60188bfb6b67da0c8a36fc75b1a70a25 https://github.com/Perl/perl5/commit/150bc24c60188bfb6b67da0c8a36fc75b1a70a25 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