[Gc] Re: Powerpc/m68k issue running test_stack
praiskup at redhat.com
Tue Dec 18 05:34:27 PST 2012
On Mon, 2012-12-17 at 15:34 +0100, Pavel Raiskup wrote:
> > 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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2859 bytes
Desc: not available
Url : https://napali.hpl.hp.com/pipermail/gc/attachments/20121218/b774071b/0001-This-works-OK.bin
More information about the Gc