On 02/23/2011 04:05 PM, Lauri T. Aarnio wrote:
On Feb 22, 2011, at 8:25 PM, ext Karol Lewandowski wrote:
Honestly, I've hard time believing that brk(2) isn't supported anymore.
Well. It won't be too surprising if brk() suffers from software rot.
I think brk() was removed from posix some ten years ago and use of it is
probably fading in any case. This is just what happens to less used
legacy features... (on the other hand, this makes me feel old; I still
remember those days when brk()/sbrk() was the only way to get more
memory for the application process from the Unix kernel :-)
brk() was probably deprecated because it forces some assumptions about
the memory map layout. It might be that those assumptions can be broken
by fancy use of setrlimit() nowadays. Fortunately it should be easy to
test it out.
Hi
I've finally got something... but it's not what I've expected. I can
reproduce this error given libsb2.so* is taken from tools environment.
Here is my testcase (you can skip [HERE])
0. Install upstream sb2 into $SB2DIR (say $HOME/lib/sb2-brk)
1. Don't randomize mmap(2) results - makes error far more visible
# sysctl -w kernel.randomize_va_space=0
2. setup Debian squeeze for tools=i386 and target=armel
# mkdir -p $HOME/s2 && cd $HOME/s2
# mkdir -p tools target var/cache/ldconfig
# sudo debootstrap --arch=i386 squeeze tools
# sudo debootstrap --arch=armel --foreign squeeze target
# cd target
# chown -R me:me .
$ sb2-init -n -N -A armel -c qemu-arm -t $HOME/s2/tools brk
$ echo scratchbox > target/debootstrap/variant
$ sb2 -eR -t brk ./debootstrap/debootstrap --second-stage
3. actual testcase
cat >Makefile <<EOF
all:
for i in `seq 1 99`; do sb2 -m devel -t brk -- echo crash >LOG.$ii
2>&1; done
Given above preparations:
[a] # make all
Works without any problems
but
[b] # cp -a $SB2DIR/lib32/libsb2 tools/usr/lib/
# make all
Fails. However, scratchbox2 _does_ work - I can login, even
compile things. But this one test fails.
From what I've learned in order to avoid taking tools from host we need
to have (1) patched libc supporting --rpath-prefix and (2) libsb2 in
tools.
However, even without patched libc sb2 dies with sig11 and it seems to
be related to default memory layout wrt direct vs indirect exec (thru
/lib/ld-linux.so*) - just like you suggested in one of previous mails.
Please compare addresses as returned by mmap(NULL..) and brk().
[a]: direct invocation (implicit/kernel loaded ld-linux.so)
17537 execve("/home/lmctl/sandbox/brk/tools/bin/bash", ["/bin/bash",
"-c", "echo crash"], [/* 61 vars */]) = 0
17537 brk(0) = 0x8114000
17537 mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0x55574000
[b]: indirect invocation
17315 execve("/home/lmctl/sandbox/brk/tools/lib/ld-linux.so.2",
["/home/lmctl/sandbox/brk/tools/li"..., "--inhibit-rpath", "",
"/home/lmctl/sandbox/brk/tools/bi"..., "-c", "echo crash"], [/* 64 vars
*/]) = 0
17315 brk(0) = 0x55572000
17315 open("/home/lmctl/sandbox/brk/tools/bin/bash", O_RDONLY) = 3
17315 read(3,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0\3\0\1\0\0\0P!\6\0104\0\0\0"...,
512) = 512
17315 fstat64(3, {st_mode=S_IFREG|0755, st_size=811156, ...}) = 0
17315 mmap2(0x8048000, 794624, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0) = 0x8048000
17315 mmap2(0x810a000, 20480, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xc1) = 0x810a000
17315 mmap2(0x810f000, 19052, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x810f000
17315 close(3) = 0
17315 mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0x55573000
This is one page after brk(0).
Oh, boy. It's unavoidable, time to look into 1500-lines-long dl_main()
from (e)glibc...
--
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
