----- Original Message -----
>
> > This seems to happen because of race between STACK_RESET and stack
> > statedump. Still thinking how to fix it without taking locks around
> > writing to file.
>
> Why should we still keep the stack being reset as part of pending pool of
> frames? Even we if we had to (can't guess why?), when we remove we should do
> the following to prevent gf_proc_dump_pending_frames from crashing.
>
> ...
>
> call_frame_t *toreset = NULL;
>
> LOCK (&stack->pool->lock)
> {
> toreset = stack->frames;
> stack->frames = NULL;
> }
> UNLOCK (&stack->pool->lock);
>
> ...
>
> Now, perform all operations that are done on stack->frames on toreset
> instead. Thoughts?
Is there a reason you want to avoid locks here? STACK_DESTROY uses the
call_pool lock to remove the stack from the list of pending frames.
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel@xxxxxxxxxxx
> http://www.gluster.org/mailman/listinfo/gluster-devel
>
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
