Leopold Toetsch wrote:
Cory Spencer <[EMAIL PROTECTED]> wrote:
I've come across another garbage collection/DOD issue that I'm trying to solve (without much success) and would appreciate some tips/advice on how to locate the source of the problem.
Running valgrind (on supported platforms, obviously) may sometimes work.
The DOD certainly has a few things flagged up, which I'm going to quickly investigate to see if they are serious or not...
Nick
e.g.
==914== Conditional jump or move depends on uninitialised value(s) ==914== at 0x80C9700: trace_mem_block (dod.c:1004) ==914== by 0x80CB9D3: trace_system_stack (cpu_dep.c:117) ==914== by 0x80CB9A1: trace_system_areas (cpu_dep.c:98) ==914== by 0x80C8F5A: Parrot_dod_trace_root (dod.c:362) ==914== by 0x80C8FB3: trace_active_PMCs (dod.c:374) ==914== by 0x80C99B9: Parrot_dod_ms_run (dod.c:1198) ==914== by 0x80C9A79: Parrot_do_dod_run (dod.c:1237) ==914== by 0x80C7920: more_traceable_objects (smallobject.c:114)
==914== Conditional jump or move depends on uninitialised value(s) ==914== at 0x80C7846: contained_in_pool (smallobject.c:55) ==914== by 0x80C85CD: is_buffer_ptr (headers.c:517) ==914== by 0x80C970F: trace_mem_block (dod.c:1004) ==914== by 0x80CB9D3: trace_system_stack (cpu_dep.c:117) ==914== by 0x80CB9A1: trace_system_areas (cpu_dep.c:98) ==914== by 0x80C8F5A: Parrot_dod_trace_root (dod.c:362) ==914== by 0x80C8FB3: trace_active_PMCs (dod.c:374) ==914== by 0x80C99B9: Parrot_dod_ms_run (dod.c:1198) ==914==
