[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7356d6ef-c3c7-6d98-0f57-ef7c2248bbf0@nonterra.com>
Date: Mon, 13 Nov 2017 20:43:50 +0100
From: Tobias Koch <tobias.koch@...terra.com>
To: musl@...ts.openwall.com
Subject: Re: diffutils crash in malloc
Hi,
I run two stacks in parallel: the target stack emulated with Qemu and a
native stack in the /tools folder. Both are cross-compiled from a
glibc-based system. In very simple cases, an application in the tools
folder is configured via
./configure --host=x86_64-cross-linux-musl --prefix=/tools
The diffutils build system seems to insist on putting libc.so in the
needed library section twice. Only the RUNPATH entry I could get rid of
via --disable-rpath. An strace of the crashing diff invocation looks
like this:
execve("/tools/bin/diff", ["/tools/bin/diff", "a", "b"], [/* 33 vars
*/]) = 0
arch_prctl(ARCH_SET_FS, 0x7f5011a98b68) = 0
set_tid_address(0x7f5011a98ba0) = 26946
open("/tools/lib/libc.so", O_RDONLY|O_CLOEXEC) = 3
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
fstat(3, {st_mode=S_IFREG|0755, st_size=3816240, ...}) = 0
read(3,
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\00055\7\0\0\0\0\0"...,
960) = 960
mmap(NULL, 2772992, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x7f5011550000
mmap(0x7f50117f0000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED,
3, 0xa0000) = 0x7f50117f0000
mmap(0x7f50117f2000, 12288, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f50117f2000
close(3) = 0
munmap(0x7f5011550000, 2772992) = 0
mprotect(0x7f5011a95000, 4096, PROT_READ) = 0
mprotect(0x635000, 4096, PROT_READ) = 0
open("/proc/self/maps", O_RDONLY) = 3
read(3, "00400000-00436000 r-xp 00000000 "..., 1024) = 997
close(3) = 0
sigaltstack({ss_sp=0x6368a0, ss_flags=0, ss_size=16384}, NULL) = 0
rt_sigprocmask(SIG_UNBLOCK, [RT_1 RT_2], NULL, 8) = 0
rt_sigaction(SIGSEGV, {sa_handler=0x4279d0, sa_mask=[HUP INT QUIT USR1
USR2 PIPE ALRM TERM CHLD URG XCPU XFSZ VTALRM PROF WINCH IO PWR], sa$
rt_sigaction(SIGSEGV, {sa_handler=0x4279d0, sa_mask=[HUP INT QUIT USR1
USR2 PIPE ALRM TERM CHLD URG XCPU XFSZ VTALRM PROF WINCH IO PWR], sa$
stat("a", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
stat("b", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
open("a", O_RDONLY) = 3
open("b", O_RDONLY) = 4
brk(NULL) = 0x63c000
brk(0x63e000) = 0x63e000
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR,
si_addr=0x7f50117f41a0} ---
open("/proc/self/maps", O_RDONLY) = 5
read(5, "00400000-00436000 r-xp 00000000 "..., 1024) = 997
close(5) = 0
write(2, "/tools/bin/diff", 15/tools/bin/diff) = 15
write(2, ": ", 2: ) = 2
write(2, "program error", 13program error) = 13
write(2, "\n", 1
) = 1
rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1 RT_2], [HUP INT QUIT USR1 SEGV
USR2 PIPE ALRM TERM CHLD URG XCPU XFSZ VTALRM PROF WINCH IO PWR], 8) $
gettid() = 26946
tkill(26946, SIGSEGV) = 0
rt_sigprocmask(SIG_SETMASK, [HUP INT QUIT USR1 SEGV USR2 PIPE ALRM TERM
CHLD URG XCPU XFSZ VTALRM PROF WINCH IO PWR], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1 RT_2], [HUP INT QUIT USR1 SEGV
USR2 PIPE ALRM TERM CHLD URG XCPU XFSZ VTALRM PROF WINCH IO PWR], 8) $
gettid() = 26946
tkill(26946, SIGABRT) = 0
rt_sigprocmask(SIG_SETMASK, [HUP INT QUIT USR1 SEGV USR2 PIPE ALRM TERM
CHLD URG XCPU XFSZ VTALRM PROF WINCH IO PWR], NULL, 8) = 0
--- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=26946,
si_uid=1000} ---
+++ killed by SIGABRT +++
Tobias
On 13/11/2017 00:05, Rich Felker wrote:
> On Sun, Nov 12, 2017 at 11:38:58PM +0100, Tobias Koch wrote:
>> Hi,
>>
>> I will try that. In the mean time, I found this piece of weirdness
>> in the readelf output:
>>
>> 0x0000000000000001 (NEEDED) Shared library:
>> [/tools/lib/libc.so]
>> 0x0000000000000001 (NEEDED) Shared library: [libc.so]
>> 0x000000000000001d (RUNPATH) Library runpath: [/tools/lib]
>>
>> Apart from being a silly duplicate, can this cause problems?
> Having multiple copies of libc in the program can definitely cause
> serious problems, and crashing in malloc seems like a very likely
> symptom. However 1.1.17 introduced logic to prevent this from
> happening. Can you describe what sort of build procedure you're using
> that's causing /tools/lib to appear here? And can you strace the
> crashing command and attach the strace output? That should show what's
> happening with shared library loading.
>
> Rich
>
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
