Re: Strange problem which involves libpthread and link flag.

[Florian Weimer <fweimer at redhat dot com>]

On 03/16/2016 11:50 PM, Goffredo Baroncelli wrote:
> Hi All,
> 
> I hope that this is the right place where post this kind of question. If this is not the case, sorry for the inconvenience and please give me a suggestion where I have to put this question.
> 
> Investigating the reason why mosh crashed on my debian machine [*], I was able to create a test case to reproduce the crash.
> 
> I have to point out that the problem which I found was not related to mosh, but (I suppose) to a strange interaction between some linker flag and the using of the pthread library.
> 
> 
> $ cat boom.c
> extern void dofork();
> 
> int main() {
>     dofork();
> }
> 
> $ cat dofork.c 
> #include <unistd.h>
> 
> void dofork() {
> 	fork();
> }
> 
> $ gcc -fPIC -c dofork.c
> $ gcc -shared -Wl,-z,now -o libdofork.so dofork.o
> $ gcc -o boom boom.c -lpthread -L$(pwd) -ldofork
> $ LD_LIBRARY_PATH=$(pwd) ./boom
> Segmentation fault
> 
> $ LD_LIBRARY_PATH=$(pwd) ldd ./boom linux-vdso.so.1 (0x00007ffe817dc000)
> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f16b38ed000)
> libdofork.so => /home/ghigo/mosh/libdofork.so (0x00007f16b36ec000)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f16b3347000)
> /lib64/ld-linux-x86-64.so.2 (0x0000562eba12a000)

Hi Goffredo,

this is a bug.  Could you report it in Bugzilla here, please?

  https://sourceware.org/bugzilla/enter_bug.cgi?product=glibc&component=nptl

I gathered the following additional information:

(gdb) break dofork
Breakpoint 1 at 0x4005b0
(gdb) r
Starting program: /home/fweimer/boom
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, 0x00007ffff79bd6d4 in dofork () from
/home/fweimer/libdofork.so
(gdb) disassemble
Dump of assembler code for function dofork:
   0x00007ffff79bd6d0 <+0>:     push   %rbp
   0x00007ffff79bd6d1 <+1>:     mov    %rsp,%rbp
=> 0x00007ffff79bd6d4 <+4>:     callq  0x7ffff79bd5c0 <fork@plt>
   0x00007ffff79bd6d9 <+9>:     nop
   0x00007ffff79bd6da <+10>:    pop    %rbp
   0x00007ffff79bd6db <+11>:    retq
End of assembler dump.
(gdb) si
0x00007ffff79bd5c0 in fork@plt () from /home/fweimer/libdofork.so
(gdb) disassemble
Dump of assembler code for function fork@plt:
=> 0x00007ffff79bd5c0 <+0>:     jmpq   *0x200a0a(%rip)        #
0x7ffff7bbdfd0 <fork@got.plt>
   0x00007ffff79bd5c6 <+6>:     pushq  $0x2
   0x00007ffff79bd5cb <+11>:    jmpq   0x7ffff79bd590
End of assembler dump.
(gdb) print *(void **)0x7ffff7bbdfd0
$1 = (void *) 0x0
(gdb)

The commit you identified, beff1d132c16aedd87a3f1bc7b572c8e69819015,
assumes that __libc_fork has been relocated before the IFUNC resolver
for the libpthread fork definition runs, which is not always true.

Florian