ferrency has asked for the wisdom of the Perl Monks concerning the following question:

I know that whenever someone claims "there's a bug in perl" they're usually wrong. I also know that pretty much everyone who does this claims to be an exception to that rule. But when you get perl to dump core during compilation, I think it's safe to say something's not working how it should.

First, some stats:

The contents of file test.pl: 

#!/usr/local/bin/perl
use test;

[download]
The contents of file test.pm: 
@A = ();
%B = ();
sub

[download]

This code is obviously wrong, but I'd expect the compiler to tell me that, not to crash:

% ./test.pl
zsh: segmentation fault  ./test.pl
% perl -c test.pl
zsh: segmentation fault  perl -c test.pl
%

I get the same behavior with various names for the files and variables. It doesn't seem to matter whether the variables are lexical or global, or whether they're hashes or arrays, but you have to have two assignments of an empty list into a non-scalar variable. And you have to do it in a "use"'d module.

Is this an undocumented feature? A known bug, or unknown? Most of my typical debugging tools aren't available to me, since it crashes during compilation.

(In my actual code, the problem ended up being relatively easy to find and fix: I accidentally left an extra sub with no code block before the final 1; in my module. I'm still curious why this happens though...)

Thanks!

Alan

Replies are listed 'Best First'.
Re: Bug in perl 5.6.0?
by Chmrr (Vicar) on Dec 20, 2001 at 01:50 UTC

    I can confirm this bug (no, a segfault is not a feature!) under 5.6.0 under Linux 2.4.7 and 5.6.1 under linux 2.4.13; Note that it's not the empty list which causes the error, but the two list assignments. Either of the following also cause segfaults:

    @a = (1..3);
@b = (4..42);
sub

    [download]

    or:

    @a = (1..3);
@a = (4..42);
sub

    [download]

    gdb's backtrace shows:

    (gdb) bt
#0  0x08078a86 in Perl_pad_free () at eval.c:41
#1  0x08078d57 in S_op_clear () at eval.c:41
#2  0x08078be9 in Perl_op_free () at eval.c:41
#3  0x08078ba8 in Perl_op_free () at eval.c:41
#4  0x08078ba8 in Perl_op_free () at eval.c:41
#5  0x08078ba8 in Perl_op_free () at eval.c:41
#6  0x08078ba8 in Perl_op_free () at eval.c:41
#7  0x080bd376 in S_doeval () at eval.c:41
#8  0x080be494 in Perl_pp_require () at eval.c:41
#9  0x08097b40 in Perl_runops_standard () at eval.c:41
#10 0x0805cd18 in S_call_body () at eval.c:41
#11 0x0805cae6 in perl_call_sv () at eval.c:41
#12 0x0805f4db in S_call_list_body () at eval.c:41
#13 0x0805f1ce in Perl_call_list () at eval.c:41
#14 0x0807fed3 in Perl_newATTRSUB () at eval.c:41
#15 0x0807d086 in Perl_utilize () at eval.c:41
#16 0x080769fa in Perl_yyparse () at eval.c:41
#17 0x0805c063 in S_parse_body () at eval.c:41
#18 0x0805b7ee in perl_parse () at eval.c:41
#19 0x08059ee9 in main () at eval.c:41

    [download]

    Looks like an "oops." Not being a core perl hacker, it doesn't mean much to me, though. Others with more clue?

    Update: Fixed a typo, thanks to crazyinsomniac. Also, this does not segfault under 5.6.0 on SunOS 5.8 -- smells like an OS-dependant bug to me..

    perl -pe '"I lo*`+$^X$\"$]!$/"=~m%(.*)%s;$_=$1;y^`+*^e v^#$&V"+@( NO CARRIER'

[reply]
[d/l]
[select]
Re: Bug in perl 5.6.0?
by VSarkiss (Monsignor) on Dec 20, 2001 at 01:43 UTC

    Hmm. If you can, consider upgrading Perl. Using 5.6.1 on HP-UX, I get: 

    syntax error at test.pm line 3, at EOF
Compilation failed in require at test.pl line 1.
BEGIN failed--compilation aborted at test.pl line 1.

    [download]
    Which is what I'd expect. Else it might be FreeBSD-specific.

    HTH

[reply]
[d/l]
      Hmm, odd. I'm running 5.6.1 on Debian Sid and am getting a segfault (which means it probably is OS specific).

      [ ar0n -- want job (boston) ]

[reply]

Back to Seekers of Perl Wisdom