tag 564074 upstream
thanks
On Thu, Jan 07, 2010 at 04:35:40PM +0200, Eugene V. Lyubimkin wrote:
> Patrick Schoenfeld wrote:
> >Apart from this: If a script language bails out with a SIGSEGV
> >this seems a lot like a interpreter bug to me.
>
> Sure. If this script contains doesn't use XS (binary) modules (which
> is unlikely, considering its dependencies).
It actually does (see /usr/lib/ftpmirror) , but the bug is not in those.
> I just cloned the bug. I am able to reproduce it on my amd64 host.
I'm attaching a testcase. The bug seems to have crept in with 5.10.1
and is still present in bleadperl.
I'm not going to start a severity war, we'll do our best to fix this for
the release anyway. I'll just note that `important' has traditionally
been the severity for perl bugs that crash the interpreter and don't
affect many packages.
Neither `grave' or `critical' fit the bill IMO. The ftpmirror package
is very much related to perl which rules out `critical', and perl is not
unusable (or mostly so) for everybody, otherwise we'd have got a lot
more bug reports.
If Eugene thinks this should be RC he's can of course set it to `serious'
as a maintainer.
Bisecting shows the bug was introduced with
http://perl5.git.perl.org/perl.git/commit/fbb3ee5af3d428706b9b8e224ae54dd344172e02
commit fbb3ee5af3d428706b9b8e224ae54dd344172e02
Author: Rafael Garcia-Suarez <rgarciasua...@gmail.com>
Date: Tue Jan 20 09:11:18 2009 +0100
Optimize away calls to empty DESTROY methods
and the 5.10.x counterpart is
http://perl5.git.perl.org/perl.git/commit/a7c1da26d681798fa9ead39f9659d043f2e1b144
commit a7c1da26d681798fa9ead39f9659d043f2e1b144
Author: Rafael Garcia-Suarez <rgarciasua...@gmail.com>
Date: Tue Jan 20 09:11:18 2009 +0100
Optimize away calls to empty DESTROY methods
(cherry picked from commit fbb3ee5af3d428706b9b8e224ae54dd344172e02)
Here's the blead backtrace. I'll report this upstream next.
Core was generated by `./miniperl /home/niko/tmp/ftpmirror-bug/564074.pl'.
Program terminated with signal 11, Segmentation fault.
#0 0x000000000054f81a in Perl_sv_clear (my_perl=0x17c9010, sv=0x17ccf60) at
sv.c:5661
5661 || CvSTART(destructor)->op_next->op_type != OP_LEAVESUB))
(gdb) bt
#0 0x000000000054f81a in Perl_sv_clear (my_perl=0x17c9010, sv=0x17ccf60) at
sv.c:5661
#1 0x0000000000551b29 in Perl_sv_free2 (my_perl=0x17c9010, sv=0x17ccf60) at
sv.c:5936
#2 0x000000000054f686 in Perl_sv_clear (my_perl=0x17c9010, sv=0x17eb970) at
sv.c:5638
#3 0x0000000000551b29 in Perl_sv_free2 (my_perl=0x17c9010, sv=0x17eb970) at
sv.c:5936
#4 0x00000000005caaeb in Perl_free_tmps (my_perl=0x17c9010) at scope.c:167
#5 0x00000000004fe647 in Perl_pp_nextstate (my_perl=0x17c9010) at pp_hot.c:54
#6 0x00000000004ba807 in Perl_runops_debug (my_perl=0x17c9010) at dump.c:2046
#7 0x000000000070a0ce in S_run_body (my_perl=0x17c9010, oldscope=1) at
perl.c:2303
#8 0x0000000000709396 in perl_run (my_perl=0x17c9010) at perl.c:2228
#9 0x00000000006d9901 in main (argc=2, argv=0x7fff97cc20b8,
env=0x7fff97cc20d0) at miniperlmain.c:117
--
Niko Tyni nt...@debian.org
#!/usr/bin/debugperl -w
M->new;
sub M::DESTROY;
sub M::new {
bless {}, 'M';
}
1;
