Front page | perl.perl5.porters |
Postings from March 2004
Re: [perl #27392] 5.8.2 cores or loops using hashref as subscript
From:
Kenneth Lorber
Date:
March 5, 2004 04:18
Subject:
Re: [perl #27392] 5.8.2 cores or loops using hashref as subscript
Message ID:
200403051158.GAA07839@lorien.office.aol.com
|From rt-brent=brentdax.com@perl.org Thu Mar 4 23:33:53 EST 2004
|Date: 5 Mar 2004 04:33:51 -0000
|Subject: Re: [perl #27392] 5.8.2 cores or loops using hashref as subscript
|From: "Brent Dax via RT" <perlbug-followup@perl.org>
|Reply-To: perlbug-followup@perl.org
|In-Reply-To: <rt-27392@perl>
|Message-ID: <rt-3.0.8-27392-80833.1.2941310206859@perl.org>
|X-RT-Loop-Prevention: perl
|RT-Ticket: perl #27392
|RT-Originator: brent@brentdax.com
|To: keni@aol.net
> foreach (@{$G->{A}{B}} ){
> print "X: $_\n";
> $G->{A}{B}[$_]{C};
> }
The hashref is being evaluated as a number, which returns the numeric
address of the referee.
Agreed.
On HP-UX, that means you're trying to access an array element with index
1,073,867,976. Presumably, HP-UX is refusing to allocate 1,073,867,977
scalars, making ary[1,073,867,976] (or thereabouts) a bad pointer. (I
don't know whether 'ary' is null or not, and I'm not really in a
position to check--I don't have a Perl with debug symbols handy.)
According to the stack trace I sent, it's not an allocation issue. The core
is occuring in the loop that's trying to assign undef to the newly created
elements; this sounds to me like there's a missing bounds check.
Tracing through with gdb, Perl_av_extend sees a key of 1073840268 at av.c:81.
At line 110, we get newmax=4 (MYMALLOC is defined in our perl build).
At 115, newmax=1073840268.
But then 118 calls Renew, which calculates the size of the memory block it
needs: (handy.h) (MEM_SIZE)((n)*sizeof(t)) - and we get an integer overflow
(1073840268+1) * 4 => 393780 (after 32bit truncation).
I think that's the bug - perl thinks it allocated more memory than it did
and when it tries to undef the new elements, boom. We need an overflow test
in (or before) the call to Renew. IMHO.
On OS X, you're trying to access element 2,667,044. Apparently this is
okay on your box (although I'm guessing Perl's eating a few extra
megabytes).
Yes, but I'd expect it to terminate after 2,667,044, but in this case
the caveat you quoted below does apply.
However, note the caveat in L<perlsyn/Foreach Loops>:
If any part of LIST is an array, foreach will get very confused
if you add or remove elements within the loop body, for example
with splice. So don't do that.
That's good advice on both of these problems, really--don't do that.
I agree - my code was in error. But I don't like being able to core an
interpreter (and not get any indication of why).
Brent "Dax" Royal-Gordon <brent@brentdax.com>
Perl and Parrot hacker
Thanks,
keni