On Fri, Jan 27, 2012 at 07:50:25PM -0800, James E Keenan via RT wrote: > I reviewed this older ticket tonight. Trimming the last post: > > ##### > On Fri Mar 05 04:19:24 2004, keni@aol.net wrote: > ... > > 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). > > > > So it appears the OP concedes he was attempting something he should not > have. When I run the attached program -- which throws 'use strict' and > 'use warnings' around the OP's code -- I get: > > ##### > $ perl 27393.pl > Useless use of hash element in void context at 27393.pl line 10. > X: 1 > X: HASH(0x1804180) > Use of reference "HASH(0x1804180)" as array index at 27393.pl line 10. > Use of uninitialized value $_ in concatenation (.) or string at 27393.pl > line 9. > X: > Use of uninitialized value $_ in array element at 27393.pl line 10. > Can't use string ("1") as a HASH ref while "strict refs" in use at > 27393.pl line 10. > ##### > > So I am amply warned of my bad behavior. I recommend we close this ticket. I disagree. The OP pointed out that the code segfaulted. Bad perl code shouldn't segfault. There appear to be a couple of possible issues; The first is modifying (extending) the array be looped over; this has traditionally been regarded as a Bad Thing to do, although I think we handle this now. The second issue is that doing $array[$ref] numfies the address of $ref and so indexes a huge array element. I think the OP's code was segfaulting when doing address calculations that overflowed a 32-bit address. IIRC, we've since hardened the array indexing code to be more robust against this sort of thing. So, I think we've *probably* fixed this. but it would be nice if someone could bisect this. It might be as simple as, doing on a 32-bit system), $a[1073840232] (based on the OP's stack trace). -- You never really learn to swear until you learn to drive.Thread Previous | Thread Next