This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Monday 14 January 2013 15:24:09 Jeff Law wrote: > This has been observed on a 32 processor power7 machine running 16 > instances of the attached testcase in parallel after a period of several > hours. i let 3 run on an ia64 dual core box for about 12 hrs and didn't see failures. which isn't to say there isn't a bug, just providing some data. > While investigating, Carlos identified that the IA64 and ARM ports have > their own unwind-forcedunwind.c implementations and that they were buggy > in regards to fencing as well. Both fail to test libgcc_s_handle and do > not have the necessary calls to atomic_read_barrier. This patch fixes > those issues as well. > > While I have extensively tested the generic unwind-forcedunwind.c change > backported to a glibc-2.12 base, I have not checked the ARM or IA64 bits > in any way. the ia64 part looks (and runs) fine. > - if (__builtin_expect (libgcc_s_personality == NULL, 0)) > + if (__builtin_expect (libgcc_s_handle == NULL, 0)) while you're here, might i suggest also doing: if (__glibc_unlikely (libgcc_s_handle == NULL)) perhaps we should even go further and make this an inline func in nptl/sysdeps/pthread/unwind-forcedunwind.c ? static __always_inline void _maybe_pthread_cancel_init (void) { if (__glibc_unlikely (libgcc_s_handle == NULL)) pthread_cancel_init (); else atomic_read_barrier (); } that way it's harder for arches to screw up because they just call: _maybe_pthread_cancel_init (); and all the magic logic stays in the common unwind file -mike
Attachment:
signature.asc
Description: This is a digitally signed message part.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |