diffutils crash in malloc

diffutils crash in malloc

[Tobias Koch]

Hi,

when I switched from musl 1.1.16 to 1.1.17 (and now 1.1.18) diff started to crash. The gdb backtrace shows, that this happens during memory allocation:

build@bootstrap(mipsel):~$ gdb /tools/bin/diff
...
Reading symbols from /tools/bin/diff...done.
(gdb) run a b
Starting program: /tools/bin/diff a b

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7d82bb7 in free (p=<optimized out>) at src/malloc/malloc.c:518
518             self->prev->next = self;
(gdb) bt
#0  0x00007ffff7d82bb7 in free (p=<optimized out>) at src/malloc/malloc.c:518
#1  0x00007ffff7d82ca5 in trim (self=self@entry=0x63c010, n=<optimized out>) at src/malloc/malloc.c:317
#2  0x00007ffff7d82f2d in malloc (n=<optimized out>, n@entry=4096) at src/malloc/malloc.c:364
#3  0x0000000000411809 in xmalloc (n=4096) at xmalloc.c:41
#4  0x0000000000408a78 in sip (current=0x7fffffffde30, skip_test=<optimized out>) at io.c:109
#5  0x0000000000408b6b in read_files (filevec=filevec@entry=0x7fffffffde30, pretend_binary=<optimized out>) at io.c:783
#6  0x0000000000404363 in diff_2_files (cmp=cmp@entry=0x7fffffffde30) at analyze.c:476
#7  0x0000000000406d10 in compare_files (parent=parent@entry=0x0, name0=<optimized out>, name1=<optimized out>) at diff.c:1433
#8  0x0000000000403870 in main (argc=<optimized out>, argv=<optimized out>) at diff.c:798

Here a and b are empty files, but this happens with other input, as well. diffutils' xmalloc looks fairly inconspicuous to me:

void *
xmalloc (size_t n)
{
  void *p = malloc (n);
  if (!p && n != 0)
    xalloc_die ();
  return p;
}

I understand this may very well be a problem in diff and not musl. But this is the exact same version of diffutils included with Debian Stretch and running the same under Valgrind compiled against glibc shows no problems. My wisdom ends here. Any clues how I can get to the bottom of this?

Tobias

Re: diffutils crash in malloc

[A. Wilcox]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 12/11/17 15:46, Tobias Koch wrote:
> Hi,
> 
> when I switched from musl 1.1.16 to 1.1.17 (and now 1.1.18) diff 
> started to crash. The gdb backtrace shows, that this happens
> during memory allocation:
> 
> build@bootstrap(mipsel):~$ gdb /tools/bin/diff

[snip]

I notice you are using mipsel.  Do you see this on any other
architectures?  diffutils compiled against 1.1.16 runs fine against
1.1.17 and 1.1.18 here on x86_64 (64-bit, LE) and ppc (32-bit, BE).
So it seems this may be a MIPS issue.

> Here a and b are empty files, but this happens with other input,
> as well. diffutils' xmalloc looks fairly inconspicuous to me:
> 
> I understand this may very well be a problem in diff and not musl. 
> But this is the exact same version of diffutils included with
> Debian Stretch and running the same under Valgrind compiled against
> glibc shows no problems. My wisdom ends here. Any clues how I can
> get to the bottom of this?
> 
> Tobias
> 

Are you using valgrind and glibc on the same hardware (mipsel)?

Best,
- --arw


- -- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJaCMI2AAoJEMspy1GSK50Uk9wQAKPpqdKvQeTFWlUuZesYET1l
8tiHBvWL3vpymOL/cJGyYvlN4rl4TZE+aZrRtxebrgnAV0BwdA0WjNHaWZ0PkRG1
i6Do8GK8pSgYJf9PtgJQLbG+qoGCj9mWDxQm3gxf2r9YGINTOevsbTwfTbvJuFWC
d1DDci7uffIhAQaYMVDm8IOmyOGGcbd91EivF9VZPNoqXcGWg9ZqMiioF+rOngJj
f4Js1YoOHPiweUQWISSIbZffb3Sex5/z5nCRoODm07k4/9ku6BrG/ACeRy5BPSR3
68iDuMahsy6jCScMDgNsWgHvDXqp/XraTF8gPdcER6noq2o98XN+ezy7aUWPWpey
SlhhmFwY3vCTyWU38gPMNw4VPtdaL+yCAy12PZQatHxkK/ck8vlTzqQ8c2FRMibk
vGT85j97MUb/ziA43+9IkGMFc9gBFZdN1T8zNCDl4c7I57cSDvn0NsiJvcFDE+2J
ThJf9ETKrougdJbCo7XIAl/JXSANVnADwd+F04uWYhyWBaA6jOYzOtQbpMM1DdeW
hgnSxmgpwJkWCk4FKufpteeuv37uP8LUeGwjd9mWn18OjDdk092D7SwnaXNAcngp
MsikPC4pzHbKSYUQ4rvHoX/qo4m7Hz9aI65eYcL3CHvX5Cfjlbv+dKI95kBM06ct
Uq1fUeUkpC55II2RlFIp
=kSn0
-----END PGP SIGNATURE-----

Re: diffutils crash in malloc

[Tobias Koch]

[-- Attachment #1: Type: text/plain, Size: 2906 bytes --]

Hi,


I should have pointed out that even though I was inside a mipsel target, the diff from the tools folder is an x86_64 binary:


build@scw-fdfceb:~/spool/mipsel$ file sys-root/tools/bin/diff

sys-root/tools/bin/diff: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /tools/lib/ld-musl-x86_64.so.1, BuildID[sha1]=80131005d1754ee60ea69e49e4d212c0ee53002a, not stripped


And this is diffutils 3.5.


Tobias


________________________________
From: A. Wilcox <awilfox@adelielinux.org>
Sent: Monday, November 13, 2017 12:50 AM
To: musl@lists.openwall.com
Subject: Re: [musl] diffutils crash in malloc

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 12/11/17 15:46, Tobias Koch wrote:
> Hi,
>
> when I switched from musl 1.1.16 to 1.1.17 (and now 1.1.18) diff
> started to crash. The gdb backtrace shows, that this happens
> during memory allocation:
>
> build@bootstrap(mipsel):~$ gdb /tools/bin/diff

[snip]

I notice you are using mipsel.  Do you see this on any other
architectures?  diffutils compiled against 1.1.16 runs fine against
1.1.17 and 1.1.18 here on x86_64 (64-bit, LE) and ppc (32-bit, BE).
So it seems this may be a MIPS issue.

> Here a and b are empty files, but this happens with other input,
> as well. diffutils' xmalloc looks fairly inconspicuous to me:
>
> I understand this may very well be a problem in diff and not musl.
> But this is the exact same version of diffutils included with
> Debian Stretch and running the same under Valgrind compiled against
> glibc shows no problems. My wisdom ends here. Any clues how I can
> get to the bottom of this?
>
> Tobias
>

Are you using valgrind and glibc on the same hardware (mipsel)?

Best,
- --arw


- --
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
Adélie Linux<http://adelielinux.org/>
adelielinux.org
Freedom over politics. Adélie Linux gives you the choice to run your system your way. Your freedom, privacy, and right of choice are what truly matters.



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJaCMI2AAoJEMspy1GSK50Uk9wQAKPpqdKvQeTFWlUuZesYET1l
8tiHBvWL3vpymOL/cJGyYvlN4rl4TZE+aZrRtxebrgnAV0BwdA0WjNHaWZ0PkRG1
i6Do8GK8pSgYJf9PtgJQLbG+qoGCj9mWDxQm3gxf2r9YGINTOevsbTwfTbvJuFWC
d1DDci7uffIhAQaYMVDm8IOmyOGGcbd91EivF9VZPNoqXcGWg9ZqMiioF+rOngJj
f4Js1YoOHPiweUQWISSIbZffb3Sex5/z5nCRoODm07k4/9ku6BrG/ACeRy5BPSR3
68iDuMahsy6jCScMDgNsWgHvDXqp/XraTF8gPdcER6noq2o98XN+ezy7aUWPWpey
SlhhmFwY3vCTyWU38gPMNw4VPtdaL+yCAy12PZQatHxkK/ck8vlTzqQ8c2FRMibk
vGT85j97MUb/ziA43+9IkGMFc9gBFZdN1T8zNCDl4c7I57cSDvn0NsiJvcFDE+2J
ThJf9ETKrougdJbCo7XIAl/JXSANVnADwd+F04uWYhyWBaA6jOYzOtQbpMM1DdeW
hgnSxmgpwJkWCk4FKufpteeuv37uP8LUeGwjd9mWn18OjDdk092D7SwnaXNAcngp
MsikPC4pzHbKSYUQ4rvHoX/qo4m7Hz9aI65eYcL3CHvX5Cfjlbv+dKI95kBM06ct
Uq1fUeUkpC55II2RlFIp
=kSn0
-----END PGP SIGNATURE-----

[-- Attachment #2: Type: text/html, Size: 6060 bytes --]

Re: diffutils crash in malloc

[A. Wilcox]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 12/11/17 16:02, Tobias Koch wrote:
> Hi,
> 
> 
> I should have pointed out that even though I was inside a mipsel
> target, the diff from the tools folder is an x86_64 binary:
> 
> 
> build@scw-fdfceb:~/spool/mipsel$ file sys-root/tools/bin/diff
> 
> sys-root/tools/bin/diff: ELF 64-bit LSB executable, x86-64, version
> 1 (SYSV), dynamically linked, interpreter
> /tools/lib/ld-musl-x86_64.so.1, 
> BuildID[sha1]=80131005d1754ee60ea69e49e4d212c0ee53002a, not
> stripped
> 
> 
> And this is diffutils 3.5.
> 
> 
> Tobias


Ah, okay.  We're using diffutils 3.6 here.  Not sure if they changed
behaviour between the point releases.  Can you try 3.6 and check if
you see the same behaviour?  If so, there may be something specific to
your environment causing it (build flags for either musl or diffutils,
for instance).

Best,
- --arw


- -- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJaCMoGAAoJEMspy1GSK50UhEUP/1M1qA4HcECNO6S6gMq9N3+J
0ow0WFt0apUXfvdtT59opHKovuoY+lmrgZ6iaonXEQYrPZUND3XLkQ3XEOG6ZIMy
kvq4okVZRkVECA3mtL8K4TUTeAMiNtDRY1rogKcIRekQOgN3O6DdPesT2qEa3icH
Yk7jUFZClHO97y5AyTQeZThjX8m7XS4r/yHkEFwDb6ESPu7La1QZeZVZrNTycUfS
vHeCYzQ1ASbb3lFwsCHi8Y5+gizikPyfdzhIW1i8VkpTMYjQAZ9/e+2kTfLherHS
IcgwJYPnLIY1YWxVP+1yW6h3S/Xu8Ktk0JKYOnu3bzvSKC7o57bvIknNop/LzE/l
NW/JbgI8sZWi+zqwDJFRAtYN5mrBdulbSlKvDmMJBpJH3d/OnDafOu6+B0zVLV3U
F39zCm39pHHAjYQERo0iKX38UBsP4D0BzbRCdUFb3sTx8FPuthJO2sIJIq0DvjJr
jCGlyFGmBJMlgTg7Tx7wLF1E8I2Jyet4tQ//B+oTMX8ufVjrLCLRyNcS4qCNXDfx
Fi681HP0NjFyMcyZXUYjwn9FaU9ljeaaEKwK0y8mE3t7RuXWxhQQPLp833zyqmc2
bMCqV3wLZtUqtMiCQkooD6n4aVujcGcfBTMuTFKsSVlbbPrikW+4PNeJnch9JBWG
oOaQlHG+fkVE1ZWcoV11
=NtG/
-----END PGP SIGNATURE-----

Re: diffutils crash in malloc

[Tobias Koch]

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?

Tobias


On 12/11/2017 23:24, A. Wilcox wrote:
> [...]
> Ah, okay.  We're using diffutils 3.6 here.  Not sure if they changed
> behaviour between the point releases.  Can you try 3.6 and check if
> you see the same behaviour?  If so, there may be something specific to
> your environment causing it (build flags for either musl or diffutils,
> for instance).
>
> [...]

Re: diffutils crash in malloc

[Rich Felker]

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


> On 12/11/2017 23:24, A. Wilcox wrote:
> >[...]
> >Ah, okay.  We're using diffutils 3.6 here.  Not sure if they changed
> >behaviour between the point releases.  Can you try 3.6 and check if
> >you see the same behaviour?  If so, there may be something specific to
> >your environment causing it (build flags for either musl or diffutils,
> >for instance).
> >
> >[...]

Re: diffutils crash in malloc

[Tobias Koch]

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
>

Re: diffutils crash in malloc

[Rich Felker]

[-- Attachment #1: Type: text/plain, Size: 2230 bytes --]

On Mon, Nov 13, 2017 at 08:43:50PM +0100, Tobias Koch wrote:
> 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

OK, you've found a bug in the new code for avoiding multiple libc
instances getting loaded if it happens at program-load time rather
than via dlopen at runtime. The code that reclaims slack space at the
edges of the writable LOAD mapping for the newly loaded library runs
before checking if the library is a duplicate of libc. If it's found
to be a duplicate, it's unloaded, and the space that was just donated
to malloc is invalid.

The attached patch should correct the issue. Note that, in order for
it to help, the copy of musl that's in /lib/ld-musl-x86_64.so.1 needs
to be updated; it is the only one that is actually running/used. If
you really want the one in /tools to be used, your $CC or $LDFLAGS
needs to include -Wl,-dynamic-linker,/tools/lib/ld-musl-x86_64.so.1 or
similar.

Rich

[-- Attachment #2: unsafe_reclaim.diff --]
[-- Type: text/plain, Size: 889 bytes --]

diff --git a/ldso/dynlink.c b/ldso/dynlink.c
index 35a90ae..fd20e92 100644
--- a/ldso/dynlink.c
+++ b/ldso/dynlink.c
@@ -725,7 +725,6 @@ done_mapping:
 	dso->base = base;
 	dso->dynv = laddr(dso, dyn);
 	if (dso->tls.size) dso->tls.image = laddr(dso, tls_image);
-	if (!runtime) reclaim_gaps(dso);
 	free(allocated_buf);
 	return map;
 noexec:
@@ -1044,6 +1043,10 @@ static struct dso *load_library(const char *name, struct dso *needed_by)
 		unmap_library(&temp_dso);
 		return load_library("libc.so", needed_by);
 	}
+	/* Past this point, if we haven't reached runtime yet, ldso has
+	 * committed either to use the mapped library or to abort execution.
+	 * Unmapping is not possible, so we can safely reclaim gaps. */
+	if (!runtime) reclaim_gaps(&temp_dso);
 
 	/* Allocate storage for the new DSO. When there is TLS, this
 	 * storage must include a reservation for all pre-existing

Re: diffutils crash in malloc

[Tobias Koch]

Hi,

I modify the cross-compiler so that it lets INTERP point to the /tools 
folder

   INTERP         0x0000000000000238 0x0000000000400238 0x0000000000400238
                  0x000000000000001f 0x000000000000001f R      0x1
       [Requesting program interpreter: /tools/lib/ld-musl-x86_64.so.1]

 From all I can tell, the patch works. Thanks a lot, Rich!

Tobias

On 13/11/2017 21:09, Rich Felker wrote:
> On Mon, Nov 13, 2017 at 08:43:50PM +0100, Tobias Koch wrote:
>> 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
> OK, you've found a bug in the new code for avoiding multiple libc
> instances getting loaded if it happens at program-load time rather
> than via dlopen at runtime. The code that reclaims slack space at the
> edges of the writable LOAD mapping for the newly loaded library runs
> before checking if the library is a duplicate of libc. If it's found
> to be a duplicate, it's unloaded, and the space that was just donated
> to malloc is invalid.
>
> The attached patch should correct the issue. Note that, in order for
> it to help, the copy of musl that's in /lib/ld-musl-x86_64.so.1 needs
> to be updated; it is the only one that is actually running/used. If
> you really want the one in /tools to be used, your $CC or $LDFLAGS
> needs to include -Wl,-dynamic-linker,/tools/lib/ld-musl-x86_64.so.1 or
> similar.
>
> Rich

Re: diffutils crash in malloc

[Rich Felker]

On Mon, Nov 13, 2017 at 09:43:15PM +0100, Tobias Koch wrote:
> Hi,
> 
> I modify the cross-compiler so that it lets INTERP point to the
> /tools folder
> 
>   INTERP         0x0000000000000238 0x0000000000400238 0x0000000000400238
>                  0x000000000000001f 0x000000000000001f R      0x1
>       [Requesting program interpreter: /tools/lib/ld-musl-x86_64.so.1]
> 
> From all I can tell, the patch works. Thanks a lot, Rich!

Thanks for reporting this and for testing it so quickly. I'm
committing the fix now and it's very helpful to know that it fixed
your problem.

Rich


> On 13/11/2017 21:09, Rich Felker wrote:
> >On Mon, Nov 13, 2017 at 08:43:50PM +0100, Tobias Koch wrote:
> >>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
> >OK, you've found a bug in the new code for avoiding multiple libc
> >instances getting loaded if it happens at program-load time rather
> >than via dlopen at runtime. The code that reclaims slack space at the
> >edges of the writable LOAD mapping for the newly loaded library runs
> >before checking if the library is a duplicate of libc. If it's found
> >to be a duplicate, it's unloaded, and the space that was just donated
> >to malloc is invalid.
> >
> >The attached patch should correct the issue. Note that, in order for
> >it to help, the copy of musl that's in /lib/ld-musl-x86_64.so.1 needs
> >to be updated; it is the only one that is actually running/used. If
> >you really want the one in /tools to be used, your $CC or $LDFLAGS
> >needs to include -Wl,-dynamic-linker,/tools/lib/ld-musl-x86_64.so.1 or
> >similar.
> >
> >Rich