Launchpad has imported 14 comments from the remote bug at
https://sourceware.org/bugzilla/show_bug.cgi?id=19861.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.
On 2016-03-23T17:47:10+00:00 Goffredo Baroncelli wrote:
I encountered this bug because mosh stopped to work after debian updated
the libc to the 2.22 [1][2]. After few tests I discovered that the
problem was related to a strange combination of switch and libs (see
below).
The minimal test case to reproduce the problem is the following:
$ cat boom.c
extern void dofork();
int main() {
dofork();
}
$ cat dofork.c
#include
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
Expected result: the program doesn't have to crash
Result: the program crashes :-)
The fatal combination seems to be "-lpthread", "-Wl,-z,now" a call to
fork() and the glibc-2.22. The crash happens near the fork.
The bug happened in mosh because:
- mosh is linked against libprotobuffer and libutempter
- mosh uses the "-Wl,-z,now" switch
- libprotobuffer via pkg-config suggests the -lpthread switch
- and libutempter uses the fork() function.
Together created the condition for the bug.
Looking at the commits between the 2.21 and 2.22 regarding nptl/pt-
fork.c, I found the following one:
commit beff1d132c16aedd87a3f1bc7b572c8e69819015
Author: Roland McGrath
Date: Fri Feb 6 10:53:07 2015 -0800
Clean up NPTL fork to be compat-only
Reverting it, the problem seems to disappear.
Florian Weimer, made some further investigation:
(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, 0x779bd6d4 in dofork () from
/home/fweimer/libdofork.so
(gdb) disassemble
Dump of assembler code for function dofork:
0x779bd6d0 <+0>: push %rbp
0x779bd6d1 <+1>: mov%rsp,%rbp
=> 0x779bd6d4 <+4>: callq 0x779bd5c0
0x779bd6d9 <+9>: nop
0x779bd6da <+10>:pop%rbp
0x779bd6db <+11>:retq
End of assembler dump.
(gdb) si
0x779bd5c0 in fork@plt () from /home/fweimer/libdofork.so
(gdb) disassemble
Dump of assembler code for function fork@plt:
=> 0x779bd5c0 <+0>: jmpq *0x200a0a(%rip)#
0x77bbdfd0
0x779bd5c6 <+6>: pushq $0x2
0x779bd5cb <+11>:jmpq 0x779bd590
End of assembler dump.
(gdb) print *(void **)0x77bbdfd0
$1 = (void *) 0x0
(gdb)
The commit beff1d132c16aedd87a3f1bc7b572c8e69819015,
assumes that __libc_fork has been relocated before the IFUNC resolver
for the libpthread fork definition runs, which is not always true.
Florian
--
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817929
[2] https://github.com/mobile-shell/mosh/issues/727
Reply at:
https://bugs.launchpad.net/ubuntu/+source/mosh/+bug/1561621/comments/0
On 2016-03-24T23:45:59+00:00 Anders Kaseorg wrote:
To reproduce on Ubuntu 16.04, I had to add -Wl,--no-as-needed before
-lpthread (to make sure the resulting binary really links
libpthread.so.0).
Reply at:
https://bugs.launchpad.net/ubuntu/+source/mosh/+bug/1561621/comments/8
On 2016-03-25T21:29:51+00:00 Florian Weimer wrote:
It turns out the IFUNC handler is not an optimization in the vfork case.
A tail call is required there because the vfork implementation has to
make sure that it can return twice even if the stack has been clobbered
(which is why the return address is loaded into a register in the i386
and x86_64 implementations).
Reply at:
https://bugs.launchpad.net/ubuntu/+source/mosh/+bug/1561621/comments/11
On 2016-04-13T18:06:14+00:00 Florian Weimer wrote:
Mailing list discussion:
https://sourceware.org/ml/libc-alpha/2016-03/msg00725.html
https://sourceware.org/ml/libc-alpha/2016-04/msg00187.html
Reply at:
https://bugs.launchpad.net/ubuntu/+source/mosh/+bug/1561621/comments/14
On 2016-05-25T14:44:11+00:00 Andrew Travneff wrote:
Created attachment 9285
fork() called from TCL
Hi all,
Have something similar with fork() called from TCL code (interpreter built from
OpenEmbedded).
fork() call in TCL lib returns __libc_fork address instead of child pid. It
works like fork() is directly replaced