Closed p5pRT closed 22 years ago
I've got this as short as possible. On Solaris the script attached causes
Attempt to free unreferenced scalar at crashit line 29\, \ chunk 3.
for perl5.00502\, or a coredump on 5.00503\, 5.00557\, 5.00558 and 5.00560. (gcc compiled)\, and 3 "attempt to free unreferenced scalar"s on 5.00560 (Sun CC v5\, 64 bit)
The coredump is in scope.c S_save_scalar_at called from Perl_save_aelem
at the line
SvMAGIC(sv) = SvMAGIC(osv);
which is because osv is an SV
{sv_any = 0x17ae78\, sv_refcnt = 2\, sv_flags = 255}
and has garbage in the xmg_magic pointer (0x200) which SEGVs when deferenced
I've used a watchpoint to track what happened to this SV at osv\, and last thing that's happened to it is that it's been freed at
#0 0xc3a90 in Perl_sv_free (sv=0x17ae60) at sv.c:3170 #1 0xa7280 in Perl_av_clear (av=0x188350) at av.c:352 #2 0xb5bc4 in Perl_pp_entersub () at pp_hot.c:2377 #3 0xa995c in Perl_runops_debug () at run.c:57 #4 0x295cc in S_run_body (args=0xffbefb60) at perl.c:1070 #5 0xec9dc in Perl_vdefault_protect (excpt=0xffbefb78\, body=0x29364 \<S_run_body>\, args=0xffbefaf8) at scope.c:44 #6 0xec8e8 in Perl_default_protect (excpt=0xffbefb78\, body=0x29364 \<S_run_body>) at scope.c:25 #7 0x29024 in perl_run (my_perl=0x16e008) at perl.c:1003 #8 0x26600 in main (argc=3\, argv=0xffbefc6c\, env=0xffbefc7c) at miniperlmain.c:53
The script is a paired down HTML (plus other stuff) parser\, and the bug goes away if I comment out two or more of the local statements.
I can probably work around the problem\, but it would be nice to blat the bug. IIRC getting shot of the the "Attempt to free unreferenced scalar" bug(s) is tricky because they are very hard to tie down.
I've just tried the script on BSDI and doesn't crash. Hmm. Maybe it's Solaris specific.
Nicholas Clark ------------------------------------------------------------------------------ #!/home/nick/perldev/bin/perl -w use strict;
sub tag {
# OK\, when we leave this scope we restore all these nesting things
local $_[3];
local $_[4];
local $_[5];
# Doing this as $_[1] to affect its pos()
$_[1] =~ m!\G(\!?\w+) # The tag itself
!gxc;
my ($argtext) = tag_args (\&tag_args\, @_[1..5]\, '');
}
# input ($coderef\,$text\,$inpre\,$ifnest\,$varnest\,$tagnest) # return ($text\, $tag) sub tag_args { while ($_[1] =~ m!([\<>]?)!gxc) { return if ($1 eq '>') } }
# input ($coderef\,$text\,$inpre\,$ifnest\,$varnest\,$tagnest\,$coderef) # return ($text\, $tag) sub parse_html { while (pos ($_[1]) \< length $_[1]) { if ($_[1] =~ /\G\</gc) { # tag my ($opentag\, $tag_type) = tag (\&parse_html\, @_[1..$#_]); } elsif ($_[1] =~ /\G([^\<]+)/gc) { } } return ''; }
while (\) { my $input = $_; pos ($input) = 0; my ($inpre\, $ifnest\, $varnest\, $tagnest); () = parse_html (undef\, $input\, $inpre\, $ifnest\, $varnest\,$tagnest); }
__DATA__ \ \
\[Too late for 5.8.0\, sorry.]
Nicholas Clark once wrote: :I've got this as short as possible.
\
This script: perl -we 'sub f { local $_[0] } f()' coredumps in leave_scope\, because (to try and take advantage of a goto) it frees the av before restoring the sv into it.
Fixing that still leaves the 'attempt to free' problems in the original code\, which can be reduced to: crypt% ./perl -we 'sub a { local($_[1]\,$_[2]\,$_[3]) } sub b { $x++ && a(0..2) for 1..2 } b() for 1..2' Name "main::x" used only once: possible typo at -e line 1. Attempt to free unreferenced scalar at -e line 1. Attempt to free temp prematurely: SV 0x814b288 at -e line 1. Attempt to free unreferenced scalar at -e line 1. crypt% .... which I haven't yet attempted to investigate.
I note that this test case still coredumps when run with '-Ds'\, though it gets further than without the patch below. I suspect that's a separate problem\, probably due to bitrot in the rarely used -Ds code.
The patch below breaks out the code it wants to goto\, so that we can conveniently call it before the SvREFCNT_dec(av)\, and fixes up similar problems in parallel branches.
This patch requires 'make regen_headers'.
Hugo
On Thu\, Jul 18\, 2002 at 05:01:57PM -0000\, Hugo van der Sanden wrote:
[Too late for 5.8.0\, sorry.]
On Thu\, Jul 18\, 2002 at 06:06:25PM +0100\, Hugo van der Sanden wrote:
[Too late for 5.8.0\, sorry.]
Would it be possible for RT not to change the message ID on the messages it spots passing through p5p? I've got a de-dup filter running on message ID\, (I believe many people have) and so I received 2 copies of Hugo's message into my inbox: 1 (either direct or via p5p\, the second would be de-duped) plus 1 helpfully sent by RT because I was the bug originator\, but not with the same message ID as the other 2.
Or does RT rely on message IDs\, and really really need to send out its messages with IDs it knows about\, so not changing them would fundamentally break it?
Nicholas Clark once wrote:
That was August 1999\, or thereabouts\, I think. That bug is the most substantial legacy of my work at boo.com (I believe that all the code written by and for us effectively got rm -rf'd ages ago\, although I wouldn't eat my shorts if someone dug up a backup of the CVS repository.)
:I've got this as short as possible.
\
Hrumph. It took me ages to get the test case down to 49 lines.
This script: perl -we 'sub f { local $_[0] } f()' coredumps in leave_scope\, because (to try and take advantage of a goto) it frees the av before restoring the sv into it.
Fixing that still leaves the 'attempt to free' problems in the original code\, which can be reduced to: crypt% ./perl -we 'sub a { local($_[1]\,$_[2]\,$_[3]) } sub b { $x++ && a(0..2) for 1..2 } b() for 1..2'
and now you've got it down to 1 slightly long line :-( And that's without using Unicode. On the basis that with Unicode I'm expecting that all programs will be reducable to 1 liners\, given the exponential increase in possible combinations of characters we will have :-)
Name "main::x" used only once: possible typo at -e line 1. Attempt to free unreferenced scalar at -e line 1. Attempt to free temp prematurely: SV 0x814b288 at -e line 1. Attempt to free unreferenced scalar at -e line 1. crypt% ... which I haven't yet attempted to investigate.
This is already way too scary for me.
I note that this test case still coredumps when run with '-Ds'\, though it gets further than without the patch below. I suspect that's a separate problem\, probably due to bitrot in the rarely used -Ds code.
Sounds like we ought to work out a way of running the regression tests with each -D option in turn.
The patch below breaks out the code it wants to goto\, so that we can conveniently call it before the SvREFCNT_dec(av)\, and fixes up similar problems in parallel branches.
Nicholas Clark -- Even better than the real thing: http://nms-cgi.sourceforge.net/
That particular message was not supposed to be sent out\, the first time\, or the second time. It leaked out during the import process. (And that was before I got tired.)
Moving forward (from yesterday) the only messages that RT should send directly to p5p are the new ticket notifications.
-R
Nicholas Clark writes:
On Thu\, Jul 18\, 2002 at 05:01:57PM -0000\, Hugo van der Sanden wrote:
[Too late for 5.8.0\, sorry.]
On Thu\, Jul 18\, 2002 at 06:06:25PM +0100\, Hugo van der Sanden wrote:
[Too late for 5.8.0\, sorry.]
Would it be possible for RT not to change the message ID on the messages it spots passing through p5p? I've got a de-dup filter running on message ID\, (I believe many people have) and so I received 2 copies of Hugo's message into my inbox: 1 (either direct or via p5p\, the second would be de-duped) plus 1 helpfully sent by RT because I was the bug originator\, but not with the same message ID as the other 2.
Or does RT rely on message IDs\, and really really need to send out its messages with IDs it knows about\, so not changing them would fundamentally break it?
Nicholas Clark once wrote:
That was August 1999\, or thereabouts\, I think. That bug is the most substantial legacy of my work at boo.com (I believe that all the code written by and for us effectively got rm -rf'd ages ago\, although I wouldn't eat my shorts if someone dug up a backup of the CVS repository.)
I'm closing this old bug report because I think its been fixed by patch #19064
@iabyn - Status changed from 'open' to 'resolved'
this still causes attempt to free unreferenced scalar in bleadperl DEVEL7093 on linux
Migrated from rt.perl.org#1176 (status was 'resolved')
Searchable as RT1176$