[Gc] Re[6]: Powerpc/m68k issue running test_stack

[Pavel Raiskup]

On Mon, 2012-12-17 at 15:34 +0100, Pavel Raiskup wrote:

Hello Ivan,

> > Ok, try another tests (master branch):
> > 
> > 1. -D AO_PREFER_GENERALIZED - if it does not help, define it
> > permanently until we fix the bug
> 
> This does not help.  OK -> I've set it permanent for now.
> 
> > 2. temporarily replace all occurrences of ..._release and ..._acquire
> > with ..._full in atomic_ops_malloc.c, ops_stack.c, ops_stack.h
> 
> Well, I tried to use _full() brothers of these calls as you said but it
> gives me still the same result -> abort() with coredump.  Other tests
> work fine even now.  I'm not sure what exactly should I switch to _full()
> -> so I redefined also the stack API the hard way :) %s/_acquire/_full/.
> Applied patch is attached.  It seems that the problem is somewhere else.
> Hopefully, I'm not doing anything bad until now.

I have tried to workaround this issue, I just used single lock for the
whole stack structure and it seems to work.  I have no idea if this is
helpful or not, but I'm attaching — even if it is piggy styled — patch
allowing stack feature to work.  This is just for info to make a proof
that some parts of libatomic_ops are ok!

I'm able (and I'd be glad) to create some more nice #ifdef solution for
you if you consider this useful for powerpc now.

I need to understand more deeply the "stack_aux" structure and how you are
using it, I still can't see whether there is guaranteed that the
background algorithm may not have collisions (considering 2+ threads
trying to make a pop and 2+ threads trying to make a push operation in
parallel).

Pavel


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-This-works-OK.patch
Type: text/x-patch
Size: 2859 bytes
Desc: not available
Url : http://napali.hpl.hp.com/pipermail/gc/attachments/20121218/b774071b/0001-This-works-OK.bin