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

Hello Monks,

I'm wondering about the following code snippet that triggers a segmentation fault if the script exit.
my $i = 30000;
my %h = (new => {});
my $r = \%h;
for (0..$i) {
   print $_, " ";
   $r = $r->{new};
   $r->{new} = {};
}
print "end\n";

[download]

Output: 
...29998 29999 30000 end
Segmentation fault (core dumped)

[download]
I test it with different iterations and from 24.000 the segfault is produced definitely. If I try to undef %h the segfault is produced immediate. 
my $i = 30000;
my %h = (new => {});
my $r = \%h;
for (0..$i) {
   print $_, " ";
   $r = $r->{new};
   $r->{new} = {};
}
undef %h;
print "end\n";

[download]

Output: 29837 29838 29839 29840 Segmentation fault (core dumped)
My question is now why that happend? Do you have an answer?

Regards,
Jonny

Edit: g0n - changed pre tags to code tags

Replies are listed 'Best First'.
Re: Segmentation fault
by Joost (Canon) on Jun 25, 2007 at 20:11 UTC
[reply]
[d/l]
      Doesn't it seem like perl should have a cleaner way of recovering from this? 
      $SIG{__ATROOSS__} = sub {
   die "about to run out of stack space!!"
};

      [download]

      This and the regexp one have always bugged the crap out of me.

      -Paul

[reply]
[d/l]
[reply]

        The problem is there is no portable way to determine that you are about to run out of stack space...

        We're not surrounded, we're in a target-rich environment!
[reply]
      Hello Joost, big thanks for your fast answer. Yes, if I increase the ulimit the script runs very fine without a stack overflow. Do you know also why the segfault is produced first if the script die and not immediate?
[reply]
        Do you know also why the segfault is produced first if the script die and not immediate?
        The stack-overflow is triggered when the top-level hash goes out of scope. In your example that is when the script ends, but that's just coincidental. If your hash goes out of scope before that, and your stack-size isn't big enough, you'll get a segfault at that point: 

        {
    my $i = 60000;
    my %h = (new => {});
    my $r = \%h;
    for (0..$i) {
       print $_, " ";
       $r = $r->{new};
       $r->{new} = {};
    }
    print "end 1\n";
} # <-- hash goes out of scope; segfault if stacksize is too low
print "end 2\n";

        [download]
        I'm not familiar with the implementation of perl's garbage collector, but I've seen this problem once before. In that case as in this one, the problem was caused by a program letting a long linked list (i.e. item a has a reference to item b which has a reference to item c etc. etc.) go out of scope.

        If you're really careful, you can clean up the linked list before it goes out of scope and prevent this error: 

        {
    my $i = 60000;
    my %h = (new => {});
    my $r = \%h;
    my $end = $r;   # end of the list
    for (0..$i) {
       print $_, " ";
       $r = $r->{new};
       $r->{new} = {};
       $r->{new}->{old} = $r;   # keep back-references
       $end = $r->{new};
    }
    print "end 1\n";
    while ($end) {  # delete the list from the end
        delete $end->{new};
        $end = delete $end->{old};
    }
}
print "end 2\n";

        [download]
        "What should it profit a man, if he should win a flame war, yet lose his cool?"
[reply]
[d/l]
[select]

Back to Seekers of Perl Wisdom