More Garbage Collection Issues
Cory Spencer
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.
It appears (based on my tests) to cause strings to be marked as dead
objects before their time. It appears to affectthe String class (in
my case, a subclass of String). Oddly, it appears to only affect strings
with a length of 1 (ie. a single character - changing the string to a
longer length does not cause it be be marked as a dead object). If I turn
DOD off with the sweepoff opcode, strings are not marked and collected.
I've also noticed similar behaviour when I use a native string type (ie.
something declared with an IMC ".local string str" declaration) as a key
in a Hash table (again, it only appears to happen when the string is a
single character in length). Later, when I go back to retrieve the value
stored in the hash, it can't find it. (Running an iterator over the keys
of the Hash shows keys that appears as garbage characters (presumably
string types that have since been collected).)
I've as of yet been unable to produce a concise, working example. Any
tips as to how I can find the source of this bug?
Leopold Toetsch
> 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.
When I'm investigating GC bugs, the usual procedure is like this:
- run the program with -t with or w/o --gc-debug
(GC bug sometimes happens earlier, which usually simplifies things)
- check the backtraces
- run it with -t -G
- compare trace outputs (possibly after reducing trace dumps with the
help of a perl script that deletes DOD/GC messages and maybe
addresses)
- try to locate which POBj (or parent(s) of it) are involved
- turn on GC_VERBOSE and set the PObj_report_FLAG in involved PMCs
- or put a printf message into destroy vtable functions
- check if parent of too early collected objects are alive and if they
mark their contents (or refs) properly
Overall: it's a nasty and time consuming job.
> ... It appears to affectthe String class (in
> my case, a subclass of String).
Does it happen with the plain String PMC too?
> ... Oddly, it appears to only affect strings
> with a length of 1 (ie. a single character - changing the string to a
> longer length does not cause it be be marked as a dead object).
Strange. How are these strings created? Some special cased code?
> I've also noticed similar behaviour when I use a native string type (ie.
> something declared with an IMC ".local string str" declaration) as a key
> in a Hash table (again, it only appears to happen when the string is a
> single character in length). Later, when I go back to retrieve the value
> stored in the hash, it can't find it. (Running an iterator over the keys
> of the Hash shows keys that appears as garbage characters (presumably
> string types that have since been collected).)
Are the strings created dynamically during an eval sequence
(compreg/compile)? String constants or outcome of a string expression?
> I've as of yet been unable to produce a concise, working example. Any
> tips as to how I can find the source of this bug?
If you can't reduce it, just send a tarball of needed stuff in PM to me.
leo
Nick Glencross
>Cory Spencer <cspe...@sprocket.org> 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==
Nick Glencross
> I've learned alot about DOD since earlier (and watched telly). Not as
> straightforward as I thought it would be to find if these traces should
> be considered serious or not (I would say any logic based on unitialised
> values will bite one day!).
Ok, now I understand. This is inspecting the C runtime stack (I think).
The Interpreter remembers the bottom address, and then when the time
comes, a routine runs the depth of the stack.
The values on the stack are then checked whether they are in the pmc or
buffer memory ranges.
I guess that there must be automatic variables which haven't been
explicitly set on the stack(?).
Last email from me on the subject,
Nick
Nick Glencross
> The DOD certainly has a few things flagged up, which I'm going to
> quickly investigate to see if they are serious or not...
I've learned alot about DOD since earlier (and watched telly). Not as
straightforward as I thought it would be to find if these traces should
be considered serious or not (I would say any logic based on unitialised
values will bite one day!).
I now know a bit more about the system stack/area, but can't quite
picture what's going on. Sorry I couldn't help more.
Probably unrelated to Cory's gremlin...
Nick
Leopold Toetsch
> Ok, now I understand. This is inspecting the C runtime stack (I think).
> The Interpreter remembers the bottom address, and then when the time
> comes, a routine runs the depth of the stack.
Yes. Exactly.
> The values on the stack are then checked whether they are in the pmc or
> buffer memory ranges.
Yes.
> I guess that there must be automatic variables which haven't been
> explicitly set on the stack(?).
No. The C runtime stack isn't explicitely written to or initialized by
running Parrot, which triggers the bogus valgrind warnings.
See F<tools/dev/parrot.supp> and:
$ cat vgp
valgrind --suppressions=tools/dev/parrot.supp --alignment=8 \
--num-callers=8 ./parrot "$@"
$ vgp some.imc
> Nick
leo