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 aurel...@aurel32.net http://www.aurel32.net
signature.asc
Description: PGP signature