develooper Front page | perl.perl5.porters | Postings from March 2004

Re: [perl #27392] 5.8.2 cores or loops using hashref as subscript

Thread Previous | Thread Next
Kenneth Lorber
March 5, 2004 04:18
Re: [perl #27392] 5.8.2 cores or loops using hashref as subscript
Message ID:
	|From 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" <>
	|In-Reply-To: <rt-27392@perl>
	|Message-ID: <>
	|X-RT-Loop-Prevention: perl
	|RT-Ticket: perl #27392

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

	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 
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 <>
	Perl and Parrot hacker

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About