Try the following on any version of Perl: 
my @h = 1..10;
bad(@h);

sub bad { 
  undef @h;
  print for @_;
}

[download]
This apparently has something to do with iterating over aliased values that have been garbage-collected. Is this a known issue? 
   MeowChow                                   
               s aamecha.s a..a\u$&owag.print

Replies are listed 'Best First'.
Re: Segfaulty
by virtualsue (Vicar) on May 15, 2001 at 15:41 UTC
    Can you expound a bit more on the issue here as you see it? Are you saying that perl itself shouldn't ever turn dubious code into something which might catch a signal and croak? From my little corner of the universe it looks to me as though the code above is asking for it and deserves whatever it gets, but that's probably not your point. ;)
[reply]

      Yes, exactly. A segfault from Perl means a bug in Perl (unless you did something nasty with the "p"/"P" formats of unpack) or a bug in an XS module.

      The "correct" behavior for the above code is to undef @h but not to free the elements previously stored in @h until they are no longer on the stack. Pushing the elements onto the stacks should increment the reference count of the elements and "mortalize" them (such that the reference counts are decremented at the next sync point which will be after that part of the stack has been discarded).

      This should be reported to p5p (though checking the bug database first would be polite). I'll be interested to see the disection of it. It may be an intentional "hole" for the sake of speed, but at this point I doubt it.

              - tye (but my friends call me "Tye")
[reply]
      I'd like to expand a bit on tye's remarks. He's right, but the reasons he's right could be a little clearer. Basically, yes, MeowChow's code is "asking for it". That's probably because he's taken a larger script (such as this, perhaps) and reduced it to the bare minimum required to cause a segfault. In a large, complicated script, it could be quite easy to have something equivalent to those lines scattered about, here and there. It would be very difficult to track that kind of bug down (especially since bad() might work fine for any arguments except @h), so we'd rather have perl just execute it correctly. The point of having garbage collection in a language like perl is that it's supposed to save us the trouble of worrying about whether we've deallocated a particular piece of memory or not.
[reply]
Re: Segfaulty
by dws (Chancellor) on May 15, 2001 at 11:44 UTC
    I would love to see the ops that Perl generates for Segfaulty, but I can't easily get to a Perl that's been compiled with debugging enabled. Would some kind soul oblige? Thanks.

    (Ah. An excuse to learn about B::Deparse.)

[reply]
Re: Segfaulty
by z0d (Hermit) on May 15, 2001 at 20:44 UTC
    I showed this bug a friend of mine. He said that it was a bug in mg.c, on line 318. Perl doubly tries to free memory.

    <-- z0d -->
[reply]
[d/l]
Re: Segfaulty
by premchai21 (Curate) on May 15, 2001 at 19:26 UTC
    B can't even seem to Deparse this. 
    Can't call method "PADLIST" on an undefined value at 
D:/Perl/lib/B/Deparse.pm line 1013.
CHECK failed--call queue aborted.

    [download]
[reply]
[d/l]

Back to Meditations