Re: diffutils crash in malloc

[Rich Felker <dalias@libc.org>]

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