On 02/16/2011 12:16 PM, Lauri T. Aarnio wrote:
On Feb 15, 2011, at 5:24 PM, ext Karol Lewandowski wrote:
19301 mprotect(0x55571000, 4096, PROT_READ) = 0
19301 brk(0) = 0x55573000
19301 brk(0x55574000) = 0x55573000
Hmm... it also fails on ubuntu 10.04/i386 machine running kernel
2.6.32-28.55 (linux-image-2.6.32-28-generic).
I've been using 2.6.32-25-server.
It is still possible that bash has some role in triggering this, since
it has it's own version of memory allocation routines. And even worse,
it exports them to the other libraries with the common names, i.e. the
bash binary contains and exports malloc(), free(), etc. Definitely a
really bad programming practice, something that I have newer understood.
But in any case, the kernel is the component which fails to allocate
memory...
It looks like bash's malloc() is to blame - it relies on false
assumption that memory after sbrk(0) is free to use. However, dynamic
linker uses mmap() to allocate memory for its data before bash is run.
For these requests kernel usually returns addresses that are
sbrk(0)+getpagesize() (with ASLR disabled this seems be always true).
Dynamic linker succeeds to allocate memory, but when bash is run it dies
in pain as it can't extend its data segment.
Recompiling bash with --without-bash-malloc (or killing /bin/bash
altogether) seems to magically solve this issue.
For some unknown reason Debian provides packages with bash using its
internal malloc implementation. I'll file bug against it.
Thanks for the hints!
--
Karol Lewandowski | Samsung Poland R&D Center | Linux/Platform
_______________________________________________
Scratchbox-devel mailing list
[email protected]
http://lists.scratchbox.org/cgi-bin/mailman/listinfo/scratchbox-devel
