Re: diffutils crash in malloc

[Tobias Koch <tobias.koch@nonterra.com>]

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
>