Peter Sinnott wrote:
[ ~300 Meg memory in t/dynclasses used ]
Probably should have tried this earlier but I have a little too
much faith in compilers. When I use gcc-2.95 it works(well all tests pass) and memory is ok. With gcc-3.3 the tests fail
and memory usage is way up. The freebsd gcc is also 3.3.3 so the
problem doesn't seem to be debian/linux/bsd related but instead
a compiler issue.
Yeah. I've now compiled it on my old linux notebook, which has gcc 3.3.3 - same problem.
What I've so far is:
(gdb)
mmd_register (interpreter=0x82dfce8, function=51, left_type=74, right_type=74,
funcptr=0x81405a0 <Parrot_default_bitwise_xors>) at src/mmd.c:585
585 offset = table->x * right_type + left_type;
1: *table = {mmd_funcs = 0x83d7bb0, x = 75, y = 75,
default_func = 0x80e5000 <mmd_fallback_stringxor_pmc>, funcs_in_table = 0}
(gdb)
586 table->mmd_funcs[offset] = funcptr;
1: *table = {mmd_funcs = 0x83d7bb0, x = 75, y = 75,
default_func = 0x80e5000 <mmd_fallback_stringxor_pmc>, funcs_in_table = 0}
(gdb)
587 }
1: *table = {mmd_funcs = 0x83d7bb0, x = 75, y = 75,
default_func = 0x80e5000 <mmd_fallback_stringxor_pmc>, funcs_in_table = 0}
(gdb)
Parrot_mmd_register_parents (interpreter=0x82dfce8, type=74, mmd_table=0xbffff430, n=53)
at src/pmc.c:502
502 for (i = 0; i < n; ++i) {
(gdb)
503 if (!mmd_table[i].right)
(gdb)
504 mmd_register(interpreter,
(gdb)
Breakpoint 3, mmd_register (interpreter=0x82dfce8, function=52, left_type=74, right_type=74,
funcptr=0x81405c0 <Parrot_default_bitwise_xors_str>) at src/mmd.c:577
577 if ((INTVAL)table->x <= left_type) {
1: *table = {mmd_funcs = 0x83dda90, x = 74, y = 262218,
default_func = 0x80e5070 <mmd_fallback_stringxor_str>, funcs_in_table = 0}
This is during registering the Foo classes* MMDs, please note the value of table->y in the last line. The value did change just between leaving the last mmd_register and entering the failing mmd_register.
Remarkable is that this is the last (highest) function number, and that
there is no other memory allocation in betweeen. And it seems to happen with --gc-debug only. Seems to be a memory corruption somewhere else.
More strange is, that my patch didn't touch any memory related things, it just increased the vtable structure by on item.
Can someone run this through valgrind or some other memory debugger please.
Above gdb snippet is from:
(gdb) bac
#0 mmd_register (interpreter=0x82dfce8, function=52, left_type=74, right_type=74,
funcptr=0x81405c0 <Parrot_default_bitwise_xors_str>) at src/mmd.c:577
#1 0x080aa1dc in Parrot_mmd_register_parents (interpreter=0x82dfce8, type=74,
mmd_table=0xbffff430, n=53) at src/pmc.c:504
#2 0x4001d726 in Parrot_Foo_class_init (interp=0x82dfce8, entry=74, pass=1) at foo.c:328
#3 0x4001d7a5 in Parrot_lib_foo_load (interpreter=0x82dfce8) at foo.c:362
#4 0x080e274e in Parrot_init_lib (interpreter=0x82dfce8,
load_func=0x4001d740 <Parrot_lib_foo_load>, init_func=0) at src/dynext.c:258
#5 0x080e28b4 in Parrot_load_lib (interpreter=0x82dfce8, lib=0x8309208, initializer=0x0)
at src/dynext.c:322
#6 0x080f9066 in Parrot_loadlib_p_sc (cur_opcode=0x8517320, interpreter=0x82dfce8)
at core.ops:1149
You reach it by first setting a breakpoint at Parrot_load_lib, then stepping over the actual library loading, then "b mmd_register".
leo
