Re: pthread_atfork on ppc64
On Mon, Jun 04, 2012 at 04:36:18PM -0500, Ryan S. Arnold wrote:
On Mon, Jun 4, 2012 at 2:20 PM, Steven Munroe
<munroesj(a)linux.vnet.ibm.com> wrote:
> On Sat, 2012-06-02 at 12:39 +0100, Richard W.M. Jones wrote:
>> As explained at length here:
>>
>> http://ryanarn.blogspot.co.uk/2011/07/curious-case-of-pthreadatfork-on.html
>>
>> on ppc64, 'pthread_atfork' is in a separate static library called
>> libpthread_nonshared.a, and libpthread.so is a linker script that
>> links both libpthread.so.0 (dynamically) and libpthread_nonshared.a
>> (statically).
>>
>
> Well Ryan is the current PPC platform maintainer in GLIBC so I will let
> him answer for himself. But as the previous platform maintainer, I can
> think of several good reasons to do this, ie to avoid nasty deadlocks
> between fork/at_fork and the ld64.so PLT resolver.
Hi Richard,
You stated in the original email that this works on x86_64 because
there's "an ordinary pthread_atfork symbol in the regular shared
library too." Unfortunately, I think you're getting lucky in that
case and picking up the older symbol version. Looking at an x86-64
fedora system I see the following:
objdump -x /lib/x86_64-linux-gnu/libpthread.so.0 | grep pthread_atfork
000000000000d450 l F .text 000000000000001c
__dyn_pthread_atfork
000000000000d450 g F .text 000000000000001c
pthread_atfork(a)GLIBC_2.2.5
Whereas, on ppc64 there is no pthread_atfork symbol in libpthread.so.0
at all, including the GLIBC 2.0 compat pthread_atfork. This is
because PPC64 support wasn't available until GLIBC 2.3, which is after
pthread_atfork was migrated to libpthread_nonshared.a.
The current/latest version of pthread_atfork exists in
libpthread_nonshared.a for ALL platforms. You can do an nm on
libpthread_nonshared.a and see this fact:
I haven't been around long enough to know WHY this was done but it
appears to have happened sometime in 2001. I suspect it was done in
order to encode a DSO handle (version) in the register_atfork call.
My thought is that /usr/lib64/ocaml/stublibs/dllthreads.so should be
statically linked with libpthread_nonshared.a sometime when it's being
built. I think simply linking with -lpthread _should_ work (but don't
use -static if you do this).
Thanks.
The upshot of all this seems to be that it's an upstream bug. Luckily
the patch required to add -lpthread is a one-liner, so I'll go ahead
and fix it in our package and file the upstream bug.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top