New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
@DB::args freed entries #11758
Comments
From zefram@fysh.orgCreated by zefram@fysh.org$ cat t0.pl $DB::args[0] is a freed scalar, freed by the "shift @a" while it was Many similar code sequences used to fail in the same way until recently. Perl Info
|
This bug is still present in Perl 5.36.0 and also blead (5.37.9)
The large program executes I put Devel::Peek::Dump calls similar to the above and got
before the panic. I will post instructions for reproducing with a (big) test case... |
STEPS TO REPRODUCE (tested with Perl v5.36.0 and 5.3.7.9):
RESULTS: You will see some commented-out debug printing near that location. Un-commenting makes the panic not happen :-( I'm hoping a core developer will know how to use a watchpoint or something to see where the specific address is being freed. |
On Tue, 14 Feb 2023, 14:52 Jim Avera, ***@***.***> wrote:
This bug is still present in Perl 5.36.0 and also blead (5.37.9)
panic: attempt to copy freed scalar ... occurs when copying @db::args
after some sequence which I can't reproduce in a small program.
The large program executes shift(@*) in a sub called with &subname so it
does not have it's own arguments but shifts the caller's @*.
I put Devel::Peek::Dump calls similar to the above and got
(several good-looking members, then...)
SV = UNKNOWN(0xff) (0x56371dea54b8) at 0x56371dea5518
REFCNT = 1
FLAGS = ()
before the panic.
What can be done to track this down?
It's a stack refcounting bug. A common pattern here is that something puts
an element of a composite structure on the stack, and then something else
empties out the composite.
Eg ***@***.***)
And then f() does @{pop @_} =(); you'll find that $_[0] has been freed.
There are *loads* of variants of this, but the general pattern is the same.
Something puts an element on the stack and something else clears the object
storing the element..
Yves
|
Hi Yves, Here is the test case [updated to rm unnecessaries]:
I hope this will help you track it down. |
I am in hospital right now. Someone else will have to help you. Sorry. |
On Tue, Feb 14, 2023 at 04:27:17PM -0800, Jim Avera wrote:
Hi Yves,
It's not bad XS code, unless the bug is in the core. I was able to make a small **pure-perl** script which causes the bug.
The bug is well understood and is hard to fix. It's down to a pair of
decades-old design flaws in perl: the argument stack isn't
reference-counted, and @db::args isn't reference-counted.
The combination of these two make it very easy for the contents of
@db::args to contain random freed or re-allocated garbage.
I've spent the last 6 months working on making perl's stack
reference-counted. In several years' time that might actually become the
default build configuration for perl. We might then be able to to address
the second short-coming in @b::args itself.
Until then, I suggest not to spend any more time on it.
…--
It's not that I'm afraid to die, I just don't want to be there when it
happens.
-- Woody Allen
|
Migrated from rt.perl.org#104074 (status was 'new')
Searchable as RT104074$
The text was updated successfully, but these errors were encountered: