Closed p5pRT closed 21 years ago
#!/usr/bin/perl
sub bar {local $_ [0] = $_ [0];}
my $str = 'foo';
bar $str; bar $str;
print $str\, "\n";
__END__
This program just prints a newline. Making small changes to the program can cause segmentation violations. Running this through valgrind gives a segmentation fault:
$ /opt/valgrind/bin/valgrind perl bug.pl ==272== valgrind-20020426\, a memory error detector for x86 GNU/Linux. ==272== Copyright (C) 2000-2002\, and GNU GPL'd\, by Julian Seward. ==272== Estimated CPU clock rate is 801 MHz ==272== For more details\, rerun with: -v ==272== ==272== Invalid read of size 4 ==272== at 0x80FAB0B: Perl_leave_scope (scope.c:719) ==272== by 0x80F8C9D: Perl_pop_scope (scope.c:136) ==272== by 0x80D0731: Perl_pp_leavesub (pp_hot.c:2286) ==272== by 0x80B3583: Perl_runops_debug (dump.c:1398) ==272== Address 0x42114B94 is 0 bytes inside a block of size 16 free'd ==272== at 0x400400A2: free (vg_clientfuncs.c:171) ==272== by 0x80B3E40: Perl_safesysfree (util.c:151) ==272== by 0x80C6421: Perl_av_undef (av.c:457) ==272== by 0x80DD281: Perl_sv_clear (sv.c:5020) ==272== ==272== Invalid write of size 4 ==272== at 0x80FAB8A: Perl_leave_scope (scope.c:727) ==272== by 0x80F8C9D: Perl_pop_scope (scope.c:136) ==272== by 0x80D0731: Perl_pp_leavesub (pp_hot.c:2286) ==272== by 0x80B3583: Perl_runops_debug (dump.c:1398) ==272== Address 0x20 is not stack'd\, malloc'd or free'd Segmentation fault
This problems happens from 5.7.0 onwards\, including in today's blead\, and also in 5.6.1. There is no problem in 5.6.0.
With blead #18932 I get the following Third Degree trace:
---------------------------------------------------------------- rih -- 7 -- scope.c: 723: reading invalid heap at byte 0 of 32-byte block Perl_leave_scope libperl.so\, scope.c\, line 723 Perl_pop_scope libperl.so\, scope.c\, line 136 Perl_pp_leavesub libperl.so\, pp_hot.c\, line 2322 Perl_runops_debug libperl.so\, dump.c\, line 1423 S_run_body libperl.so\, perl.c\, line 1582 perl_run libperl.so\, perl.c\, line 1501 main perl\, perlmain.c\, line 85 __start perl
This block at address 0x14001e830 was allocated at: malloc libc.so Perl_safesysmalloc libperl.so\, util.c\, line 69 Perl_av_extend libperl.so\, av.c\, line 150 Perl_pad_tidy libperl.so\, pad.c\, line 1063 Perl_newATTRSUB libperl.so\, op.c\, line 4150 Perl_yyparse libperl.so\, perly.c\, line 1699 S_parse_body libperl.so\, perl.c\, line 1426 perl_parse libperl.so\, perl.c\, line 932 main perl\, perlmain.c\, line 83 __start perl
This block was freed at: free libc.so Perl_safesysfree libperl.so\, util.c\, line 142 Perl_av_undef libperl.so\, av.c\, line 497 Perl_sv_clear libperl.so\, sv.c\, line 5380 Perl_sv_free2 libperl.so\, sv.c\, line 5574 Perl_sv_free libperl.so\, sv.c\, line 5554 Perl_leave_scope libperl.so\, scope.c\, line 972 Perl_pop_scope libperl.so\, scope.c\, line 136 Perl_pp_leavesub libperl.so\, pp_hot.c\, line 2322 Perl_runops_debug libperl.so\, dump.c\, line 1423 S_run_body libperl.so\, perl.c\, line 1582 perl_run libperl.so\, perl.c\, line 1501 main perl\, perlmain.c\, line 85 __start perl
On Tue\, Mar 11\, 2003 at 08:07:20PM -0000\, abigail@abigail.nl (via RT) wrote:
\#\!/usr/bin/perl sub bar \{local $\_ \[0\] = $\_ \[0\];\} my $str = 'foo'; bar $str; bar $str; print $str\, "\\n"; \_\_END\_\_
This program just prints a newline. Making small changes to the program can cause segmentation violations.
It's two related problems to do with the reification (is that a word?) of @_.
The local() causes a SAVEt_AELEM to be pushed onto the savestack. When the element is retored on scope exit\, the array is reified\, causing the refcount of the restored element to be off by one. One half of this patch fixes the SAVEt_AELEM code to handle this possibility.
In addition\, the scope exit (LEAVE) is currently done after the POPSUB - which checks for a reified @_ and abandons it if necessary. So the check for reification comes too late. The second half of this patch moves the various LEAVEs to before the POPSUBs. This half I am more unsure about\, but it seems to pass the tests...
-- Standards (n). Battle insignia or tribal totems.
On Thu\, Mar 20\, 2003 at 01:26:19AM +0000\, Dave Mitchell wrote:
It's two related problems to do with the reification (is that a word?) of @_.
Adi has pointed out to me a further coredump - this patch (to be applied on top of the previous one) fixes that too. The various paths to the restore_sv: branch in leave_scope() all decremeted the ref count of the aggregate (av\, hv or gv)\, then restored the element. If the aggregate had a count of 1\, this could coredump. Now we restore\, *then* decrement.
Dave.
-- Justice is when you get what you deserve. Law is when you get what you pay for.
Adi has pointed out to me a further coredump - this patch (to be applied on top of the previous one) fixes that too.
Both patches now applied (change #19064).
-- Jarkko Hietaniemi \jhi@​iki\.fi http://www.iki.fi/jhi/ "There is this special biologist word we use for 'stable'. It is 'dead'." -- Jack Cohen
closing call\, as I think I've fixed it....
@iabyn - Status changed from 'new' to 'resolved'
Migrated from rt.perl.org#21542 (status was 'resolved')
Searchable as RT21542$