Strange GC problem on the threads branch.

Jonathan "Duke" Leto jonathan at leto.net
Thu Dec 8 16:57:49 UTC 2011


Howdy,

I suggest increasing the test coverage of Parrot_Pointer_Array as a first step
to fixing/debugging this problem.

Duke

On Thu, Dec 8, 2011 at 1:22 AM, Stefan Seifert <nine at detonation.org> wrote:
> 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
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>



-- 
Jonathan "Duke" Leto <jonathan at leto.net>
Leto Labs LLC
209.691.DUKE // http://labs.leto.net
NOTE: Personal email is only checked twice a day at 10am/2pm PST,
please call/text for time-sensitive matters.


More information about the parrot-dev mailing list