Bug 1326903

Created attachment 1146922 [details]
foo.c

Version-Release number of selected component (if applicable):
glibc-2.22-11.fc23.x86_64
gpgme-1.4.3-6.fc23.x86_64

How reproducible:
With the attachment,
> $ gcc -Wall -Wextra -O2 foo.c -lpthread -lgpgme
> $ ./a.out 
>Segmentation fault (core dumped)

> gdb ./a.out; # r; up; disassemble …
>   0x00007ffff79ab760 <+320>:	callq  0x7ffff798e3f0 <fork@plt>
> (gdb) disassemble 0x7ffff798e3f0
>Dump of assembler code for function fork@plt:
>   0x00007ffff798e3f0 <+0>:	jmpq   *0x22fb82(%rip)        # 0x7ffff7bbdf78 <fork>
>   0x00007ffff798e3f6 <+6>:	pushq  $0x8a
>   0x00007ffff798e3fb <+11>:	jmpq   0x7ffff798db40
> (gdb) x/a 0x7ffff7bbdf78
> 0x7ffff7bbdf78 <fork>:	0x0

This depends on -lpthread being before -lgpgme: This does not crash when -lpthread is removed, when the order is switched (-lgpgme -lpthread), or when -pthread is used (which effectively moves -lpthread to the end).

AFAICS this happens because a.out's DT_NEEDED are in the order of [libpthread; libgpgme; libc], and relocation happens in reverse order, i.e. libgpgme is relocated before libpthread, and libgpgme.so has DT_BIND_NOW set.

Therefore, gpgme’s relocation includes relocation of gpgme:fork, which is resolved to libpthread’s fork_resolve ifunc; in turn, this ifunc is immediately called, returning an entry from libpthread’s GOT for __libc_fork ­— but libpthread has not been relocated yet, so libpthread:__libc_fork@got is NULL, so libgpgme:fork is set to NULL as well. (Without DT_BIND_NOW, gpgme:fork would be lazily resolve after libpthread:__libc_fork@got is correctly relocated.)


This does not crash on F22 with
> glibc-2.21-13.fc22.x86_64
> gpgme-1.4.3-5.fc22.x86_64
One reason is that gpgme is not compiled with DT_BIND_NOW in this version, but apparently the primary difference is glibc: with a stub gpgme replacement (attached):
> gcc -shared -Wl,-z,now -Wall -Wextra -fPIC -o libmyso.so myso.c
> gcc -Wall -Wextra -O2 foo.c -lpthread ./libmyso.so 
> ./a.out
crashes on F23, but not on F22.


AFAICS there is no official documentation to suggest that adding -lpthread is unsupported: (info gcc) only documents -pthread; in fact c99(1P) explicitly documents “-l pthread” as the portable way to