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] |