Well, there's a bummer. The following code segfaults Tru64.
set S0, "ba"
rx_allocinfo P0, S0
rx_setprops P0, "", 0
rx_succeed P0
rx_info_getstartindex P0, I1
rx_info_getindex P0, I2
length I3, S0
substr S1, S0, 0, I1
sub I4, I2, I1
substr S2, S0, I1, I4
sub I4, I3, I2
substr S3, S0, I2, I4
# Needs to be four constant prints
print "this "
print "will "
print "seg"
print "fault\n"
end
We're seeing some corruption in the memory pool, as evidenced here:
(gdb) run test.pbc
Starting program: /v0/xzdg/simon/parrot/./test_parrot test.pbc
Program received signal SIGSEGV, Segmentation fault.
0x120065630 in new_string_header (interpreter=0x140052000) at resources.c:649
649 return_me->flags = BUFFER_live_FLAG;
(gdb) print return_me
$1 = (struct parrot_string_t *) 0x61
It dawns on me that I have absolutely no idea how these lines are expected
to work:
644 /* Dereference the buffer pointer to get the real string pointer */
645 return_me = *foo;
We still claim to have plenty of headers available:
(gdb) print interpreter->arena_base->string_header_pool->entries_in_pool
$2 = 243
interpreter->arena_base->string_header_pool->pool_buffer.bufstart+244
and interpreter->arena_base->string_header_pool->pool_buffer.bufstart+241
give sensible results, but +242 and +243 are definitely not sensible places
to start strings. What's going on?
Simon
--
Anything to do with HTML processing /usually/ involves a pact
with an evil supernatural being, I find.
-- Sean Burke
