On 2018-12-22 19:42, Tim Rühsen wrote:
> On 22.12.18 16:56, Aurelien Jarno wrote:
> > The problem is that qemu-arm does not provide a heap to the program, so
> > glibc fails to alloc memory through brk. This causes malloc to switch to
> > mmap based memory allocation, and this also sets errno to ENOMEM.
> >
> > printf also calls malloc, so the malloc implementation switches to
> > mmap based memory allocation at this moment. This is remembered through
> > the life of the program. When strerror then calls malloc(1024), the
> > allocation is done directly through mmap and errno is not set to ENOMEM.
Setting errno to ENOMEM happens during the call to MORECORE/sbrk in
malloc/malloc.c in the following lines of the sysmalloc function:
| if (size > 0)
| {
| brk = (char *) (MORECORE (size));
| LIBC_PROBE (memory_sbrk_more, 2, brk, size);
| }
Note however that clobbering errno is allowed even in case of success,
unless the contrary is specifically documented.
> > That's why you do not see the issue.
> >
> > To reproduce the issue, you therefore need the following conditions:
> > - The kernel or QEMU does not provide a heap to the program
> > - malloc is not called (implicitly or explicitly) before the call to
> > strerror
> > - strerror is called with an invalid error number.
> >
> > If all of this 3 conditions are not met, the bug does not appear.
>
> That is a good explanation and makes sense to me, thank you, Aurelien.
>
> At least we can work around that issue now.
>
> BTW, how do you debug cross-compiled executables ? There is no cross-gdb
> packaged in debian (or is there ?). Building that from scratch seems too
> time-intensive...
I have been rebuilding glibc, directly modifying the code being
debugged. ccache is really useful in that case.
Regards,
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
Attachment:
signature.asc
Description: PGP signature