* diffutils crash in malloc
@ 2017-11-12 21:46 Tobias Koch
2017-11-12 21:50 ` A. Wilcox
0 siblings, 1 reply; 10+ messages in thread
From: Tobias Koch @ 2017-11-12 21:46 UTC (permalink / raw)
To: musl
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
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: diffutils crash in malloc 2017-11-12 21:46 diffutils crash in malloc Tobias Koch @ 2017-11-12 21:50 ` A. Wilcox 2017-11-12 22:02 ` Tobias Koch 0 siblings, 1 reply; 10+ messages in thread From: A. Wilcox @ 2017-11-12 21:50 UTC (permalink / raw) To: musl -----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----- ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: diffutils crash in malloc 2017-11-12 21:50 ` A. Wilcox @ 2017-11-12 22:02 ` Tobias Koch 2017-11-12 22:24 ` A. Wilcox 0 siblings, 1 reply; 10+ messages in thread From: Tobias Koch @ 2017-11-12 22:02 UTC (permalink / raw) To: musl [-- 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 --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: diffutils crash in malloc 2017-11-12 22:02 ` Tobias Koch @ 2017-11-12 22:24 ` A. Wilcox 2017-11-12 22:38 ` Tobias Koch 0 siblings, 1 reply; 10+ messages in thread From: A. Wilcox @ 2017-11-12 22:24 UTC (permalink / raw) To: musl -----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----- ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: diffutils crash in malloc 2017-11-12 22:24 ` A. Wilcox @ 2017-11-12 22:38 ` Tobias Koch 2017-11-12 23:05 ` Rich Felker 0 siblings, 1 reply; 10+ messages in thread From: Tobias Koch @ 2017-11-12 22:38 UTC (permalink / raw) To: musl 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). > > [...] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: diffutils crash in malloc 2017-11-12 22:38 ` Tobias Koch @ 2017-11-12 23:05 ` Rich Felker 2017-11-13 19:43 ` Tobias Koch 0 siblings, 1 reply; 10+ messages in thread From: Rich Felker @ 2017-11-12 23:05 UTC (permalink / raw) To: musl 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). > > > >[...] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: diffutils crash in malloc 2017-11-12 23:05 ` Rich Felker @ 2017-11-13 19:43 ` Tobias Koch 2017-11-13 20:09 ` Rich Felker 0 siblings, 1 reply; 10+ messages in thread From: Tobias Koch @ 2017-11-13 19:43 UTC (permalink / raw) To: musl 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 > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: diffutils crash in malloc 2017-11-13 19:43 ` Tobias Koch @ 2017-11-13 20:09 ` Rich Felker 2017-11-13 20:43 ` Tobias Koch 0 siblings, 1 reply; 10+ messages in thread From: Rich Felker @ 2017-11-13 20:09 UTC (permalink / raw) To: musl [-- 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: diffutils crash in malloc 2017-11-13 20:09 ` Rich Felker @ 2017-11-13 20:43 ` Tobias Koch 2017-11-13 20:51 ` Rich Felker 0 siblings, 1 reply; 10+ messages in thread From: Tobias Koch @ 2017-11-13 20:43 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: diffutils crash in malloc 2017-11-13 20:43 ` Tobias Koch @ 2017-11-13 20:51 ` Rich Felker 0 siblings, 0 replies; 10+ messages in thread From: Rich Felker @ 2017-11-13 20:51 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2017-11-13 20:51 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-11-12 21:46 diffutils crash in malloc Tobias Koch 2017-11-12 21:50 ` A. Wilcox 2017-11-12 22:02 ` Tobias Koch 2017-11-12 22:24 ` A. Wilcox 2017-11-12 22:38 ` Tobias Koch 2017-11-12 23:05 ` Rich Felker 2017-11-13 19:43 ` Tobias Koch 2017-11-13 20:09 ` Rich Felker 2017-11-13 20:43 ` Tobias Koch 2017-11-13 20:51 ` Rich Felker
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).