On Sun, Jan 29, 2012 at 08:56:49PM +0000, Dave Mitchell wrote: > 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). I'm finding it really hard to replicate the OP's problem. The memory map on Linux (at least x86), FreeBSD (x86), OS X (x86) and AIX (Power?) doesn't fail in the right way. I have this suspicion that ia64 Linux would sort of be right, except that it's (obviously) not 32 bit. :-) $ perl -MConfig -le 'print "$Config{archname}: " . []' ia64-linux-gnu-thread-multi: ARRAY(0x6000000000024120) Note how the heap isn't at the bottom of address space. The OP was on HP/UX. I don't have access to HP/UX Nicholas ClarkThread Previous | Thread Next