On Feb 16, 2011, at 6:53 PM, ext Karol Lewandowski wrote:
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.
That is bad, really bad. Having a common, old, widely used program
which relies on a false assumption means that that false assumption
has now practically turned to a requirement. Which isn't met anymore.
Even if bash is now recompiled by debian, it still leaves countless
amount of installation where the bug exists in binaries. Binaries that
happen to work magically outside of sb2, but fail when executed with
sb2.
All this makes it look like the problem was in sb2 (another false
assumption), and that is what worries me now. Especially because it
wasn't too easy to find this out, was it? And there may even be other
programs that use similar memory allocation practices & requirements.
I'd guess that no one wants to analyze those one-by-one, if these kind
of problems start to appear in a different context someday.
Fortunately the fix is easy, at least in theory. And it wouldn't be
the first time when sb2 is used to fix somebody else's problems:
Probably we should replace brk() and sbrk() completely. For example,
by introducing new versions that do not use the brk syscall, but
instead mmap() a block of anonymous memory, and then let applications
reserve memory from there.
I did some prototyping today and found out that this is not as
straightforward as it sounds. glibc uses sbrk internally, and sbrk is
a weak alias there, which means for example that strdup() instantly
ends up calling our version of sbrk... Trying to add a simple wrapper
for brk and sbrk failed because of that. So compatibility with glibc
needs to be taken into account, and it will very probably cause some
additional pain before this feature can be finalized.
Conclusion was that more work is needed to solve the remaining issues.
Unfortunately it seems that I don't have time to continue with this in
the near future, maybe later..
Lauri
PS. It seems that "interesting" memory management practices have been
common in shells; See this paper about the original Bourne shell: http://www.collyer.net/who/geoff/sh.tour.ps
_______________________________________________
Scratchbox-devel mailing list
[email protected]
http://lists.scratchbox.org/cgi-bin/mailman/listinfo/scratchbox-devel
