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
Created attachment 1146923 [details] myso.c
This is a known issue (see the upstream bug). We can fix fork easily enough, but a fix for vfork may be more difficult.
glibc-2.23.1-8.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-3c5d606035
glibc-2.22-17.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-b2dfb591cd
glibc-2.23.1-8.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-3c5d606035
glibc-2.22-17.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-b2dfb591cd
glibc-2.22-17.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
glibc-2.23.1-8.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.