On Tuesday 06 December 2011 21:32:47 Stefan Seifert wrote: > From what I could discover, the main problem is that Parrot_Task_mark only > gets called once. After that the task's code and data are collected by the > GC. The debug output and single stepping in gdb shows that > gc_gms_process_work_list finds the task and adds it to self->objects[gen]. > Immediately afterwards gc_gms_sweep_pools runs but the task is missing in > the list. So the task never gets sweeped and it's live flag does not get > reset. So the next time the GC runs the task is already marked and > Parrot_Task_mark not called anymore.
I found futher indications that the source of the problem really lies in the
Parrot_Pointer_Array. The pointer array essentially seems to be a linked list
of array chunks. On deleting an element in the array the slot in the chunk is
marked as empty by setting the least significant bit. Parrot_pa_insert later
tries to re-use this slot. If I deactivate the mechanism by the following
patch, my problem disappears and my test program runs stable:
--- a/include/parrot/pointer_array.h
+++ b/include/parrot/pointer_array.h
@@ -122,12 +122,13 @@ Parrot_pa_insert(PARROT_INTERP,
ARGIN(Parrot_Pointer_Array *self), ARGIN(void *p
allocate_more_chunks(interp, self);
/* Reuse removed cell */
- if (self->next_free) {
+ if (0 && self->next_free) {
/* FIXME. Cast to UINTVAL is wrong. */
I have no idea why this problem only occures in my test program using threads.
When I just use the same GC for both threads, the problem vanishes as well (of
course only as long as the main thread is inactive). Maybe someone more
familiar with this code can lighten things up a bit?
Thanks anyway,
Stefan
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
