This is the smallest bit of code I could get to segfault in my linux
dev box:
----
sub main () {
my $string =
"****************************************************************************************************************************************************************************************************************************************************************";
for 1..11 {
print1 "in loop $_\n";
substr ($string, $_, 1);
substr ($string, $_, 1);
substr ($string, $_, 1);
substr ($string, $_, 1);
substr ($string, $_, 1);
substr ($string, $_, 1);
substr ($string, $_, 1);
substr ($string, $_, 1);
substr ($string, $_, 1);
substr ($string, $_, 1);
substr ($string, $_, 1);
substr ($string, $_, 1);
substr ($string, $_, 1);
substr ($string, $_, 1);
substr ($string, $_, 1);
}
print "made it past substr\n";
}
----
15 calls to 'substr' in each loop segfaults (14 doesn't), and it always
segfaults on the 11th loop.
To confirm my suspicion, I ran gdb on the generated PIR code from the
original source:
$ gdb parrot
# and from the gdb prompt
(gdb) run life.imc
# and when it segfaulted
(gdb) back
----
#0 0x401571b7 in memcpy () from /lib/libc.so.6
#1 0x08158c41 in compact_pool (interpreter=0x82ebf90, pool=0x82ec770)
at src/resources.c:341
#2 0x08158923 in mem_allocate (interpreter=0x82ebf90, req_size=0xbffff3e8,
pool=0x82ec770, align_1=15) at src/resources.c:154
#3 0x081591f2 in Parrot_allocate (interpreter=0x82ebf90, buffer=0x4148e0d8,
size=64) at src/resources.c:603
#4 0x0815922e in Parrot_allocate_zeroed (interpreter=0x82ebf90,
buffer=0x4148e0d8, size=64) at src/resources.c:625
#5 0x080d7638 in allocate_chunk (interpreter=0x82ebf90, list=0x8416800,
items=16, size=64) at src/list.c:240
#6 0x080d8013 in alloc_next_size (interpreter=0x82ebf90, list=0x8416800,
where=1, idx=1) at src/list.c:667
...
----
So, this is where I hand it off to Leo. It may be a known bug in Parrot,
or maybe not.
Allison
