This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: [!!Mass Mail]Strange problem which involves libpthread and link flag.
- From: Sergey Gvozdetskiy <gvozdetskiy at corp dot sputnik dot ru>
- To: <kreijack at inwind dot it>, <libc-help at sourceware dot org>
- Date: Thu, 17 Mar 2016 11:39:13 +0300
- Subject: Re: [!!Mass Mail]Strange problem which involves libpthread and link flag.
- Authentication-results: sourceware.org; auth=none
- References: <56E9E31D dot 9070403 at inwind dot it>
Hello, Goffredo, and everybody!
this bug doesn't happen with libc-2.21 and gcc version 4.9.3 too.
My strace of this one example:
$ LD_LIBRARY_PATH=$(pwd) strace ./boom
execve("./boom", ["./boom"], [/* 91 vars */]) = 0
brk(0) = 0x1f39000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x7ff1e40f4000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or
directory)
open("/home/gvozdetskiy/tmp/src/tls/x86_64/libdofork.so",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/home/gvozdetskiy/tmp/src/tls/x86_64", 0x7fffde6a46d0) = -1 ENOENT
(No such file or directory)
open("/home/gvozdetskiy/tmp/src/tls/libdofork.so", O_RDONLY|O_CLOEXEC) =
-1 ENOENT (No such file or directory)
stat("/home/gvozdetskiy/tmp/src/tls", 0x7fffde6a46d0) = -1 ENOENT (No
such file or directory)
open("/home/gvozdetskiy/tmp/src/x86_64/libdofork.so",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/home/gvozdetskiy/tmp/src/x86_64", 0x7fffde6a46d0) = -1 ENOENT (No
such file or directory)
open("/home/gvozdetskiy/tmp/src/libdofork.so", O_RDONLY|O_CLOEXEC) = 3
read(3,
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\320\5\0\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0775, st_size=7760, ...}) = 0
mmap(NULL, 2101264, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x7ff1e3cd1000
mprotect(0x7ff1e3cd2000, 2093056, PROT_NONE) = 0
mmap(0x7ff1e3ed1000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0) = 0x7ff1e3ed1000
close(3) = 0
open("/home/gvozdetskiy/tmp/src/libc.so.6", O_RDONLY|O_CLOEXEC) = -1
ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=118554, ...}) = 0
mmap(NULL, 118554, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ff1e40d7000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
directory)
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3,
"\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`\v\2\0\0\0\0\0"..., 832)
= 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1869392, ...}) = 0
mmap(NULL, 3972864, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x7ff1e3907000
mprotect(0x7ff1e3ac7000, 2097152, PROT_NONE) = 0
mmap(0x7ff1e3cc7000, 24576, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1c0000) = 0x7ff1e3cc7000
mmap(0x7ff1e3ccd000, 16128, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7ff1e3ccd000
close(3) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x7ff1e40d6000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x7ff1e40d5000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x7ff1e40d4000
arch_prctl(ARCH_SET_FS, 0x7ff1e40d5700) = 0
mprotect(0x7ff1e3cc7000, 16384, PROT_READ) = 0
mprotect(0x7ff1e3ed1000, 4096, PROT_READ) = 0
mprotect(0x600000, 4096, PROT_READ) = 0
mprotect(0x7ff1e40f6000, 4096, PROT_READ) = 0
munmap(0x7ff1e40d7000, 118554) = 0
clone(child_stack=0,
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0x7ff1e40d59d0) = 24024
exit_group(24024) = ?
+++ exited with 216 +++
Return value after execute ./boom was 36, 40, 43, etc.
Same strace out(with minimal differents) I had, while use gcc version
5.2.1.
Return value of it, was 0.
Ubuntu 15.10, gcc's from repo.
It for more details, may be helpful.))
Best regards!
On 03/17/2016 01:50 AM, 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)
$ dpkg --list | grep libc6
ii libc6:amd64 2.22-3
I was able to reproduce this bug also in a Fedora F23 machine (=libc 2.22). The bug happens even with different compiler versions (gcc-4.8, gcc-6, gcc-5.3, clang-3.8). In another regular debian machine equipped with libc-2.19 the crash doesn't happen. All the machines tested are linux x86-64.
In order to reproduce this problem:
- use the "-Wl,-z,now" in the shared library
- put fork() in the shared library
- compile the main program with "-lpthread" before the "-l<shared library>" (the order matters !)
So my questions are:
- I am wrong to suppose that this code should not crash ?
- I know that -lpthread is not needed, but is it forbid to use it even if not needed ? With -pthread only, the code works without problem (mosh too !)
- Could the problem be libc/pthread related ?
BR
G.Baroncelli
[*] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817929
mosh problem