|
From: Tom H. <to...@co...> - 2006-09-08 18:58:27
|
In message <115...@ok...>
Alex Bennee <ker...@be...> wrote:
> I should of looked more closely at the syscalls
>
> setPid 15817 (@0x424f5f8)
> ..
> ..
> getLock tc=0x424e208, pid=15817
> SYSCALL[15817,1]( 1) ... [async] --> Success(0x20)
> SYSCALL[15817,1]( 9) sys_mmap ( 0x6C000, 198787072, 7, 50, -1, 0 )==15817== Warning: set address range perms: large range 198787072 (defined) --> [pre-success] Success(0x6C000)
> SYSCALL[15817,1]( 9) sys_mmap ( 0x2A96000000, 4096, 1, 34, -1, 0 ) --> [pre-success] Success(0xBE00000)
> SYSCALL[15817,1]( 11) sys_munmap ( 0xBE00000, 4096 )[sync] --> Success(0x0)
> SYSCALL[15817,1]( 1) sys_write ( 2, 0x7FEFFC070, 28 ) --> [async] ...
> getLock tc=0x424e208, pid=0
>
> We let our subject application mmap right over our heap area.
Using a fixed mmap is a fairly dangerous thing to do...
You are mmaping 0x6c000 to 0xbe00000 as a fixed mapping which makes me
susprised that anything ever works as even without valgrind that is
likely to wipe out the executable and the heap - this is the map for
a basic process on one of my 64 bit machines without valgrind:
00400000-00405000 r-xp 00000000 fd:00 18350129 /bin/cat
00504000-00506000 rw-p 00004000 fd:00 18350129 /bin/cat
00506000-00527000 rw-p 00506000 00:00 0 [heap]
347f100000-347f11a000 r-xp 00000000 fd:00 6144028 /lib64/ld-2.4.so
347f219000-347f21a000 r--p 00019000 fd:00 6144028 /lib64/ld-2.4.so
347f21a000-347f21b000 rw-p 0001a000 fd:00 6144028 /lib64/ld-2.4.so
347f300000-347f43f000 r-xp 00000000 fd:00 6144043 /lib64/libc-2.4.so
347f43f000-347f53f000 ---p 0013f000 fd:00 6144043 /lib64/libc-2.4.so
347f53f000-347f543000 r--p 0013f000 fd:00 6144043 /lib64/libc-2.4.so
347f543000-347f544000 rw-p 00143000 fd:00 6144043 /lib64/libc-2.4.so
347f544000-347f549000 rw-p 347f544000 00:00 0
2aaaaaaab000-2aaaaaaac000 rw-p 2aaaaaaab000 00:00 0
2aaaaaad5000-2aaaaaad7000 rw-p 2aaaaaad5000 00:00 0
7fff1e76f000-7fff1e785000 rw-p 7fff1e76f000 00:00 0 [stack]
ffffffffff600000-ffffffffffe00000 ---p 00000000 00:00 0 [vdso]
Your fixed mapping would wipe out the executable and heap on that...
> I tried messing around with valgrind's configure to leave enough space for
> us, however:
>
> cat /proc/15817/maps
> <snip>
> 6ff00000-70377000 r-xp 00000000 00:18 1552482 dynamite
> 70477000-7048a000 rw-p 00477000 00:18 1552482 dynamite
> 7048a000-704d3000 rw-p 7048a000 00:00 0
> 704d3000-704d4000 rwxp 704d3000 00:00 0
> 78000000-78169000 r-xp 00000000 08:03 35037 /usr/local/lib/valgrind/amd64-linux/memcheck
> 78269000-7826a000 rw-p 00169000 08:03 35037 /usr/local/lib/valgrind/amd64-linux/memcheck
> <snip>
>
> It looks as though our binary is where it wants to be the heap itself
> has moved down into memory. There are two options I think of:
>
> 1. Stop Valgrind relocating the heap
Valgrind doesn't relocate the heap as such - it creates an emulated
heap for the client. On x86 it winds up immediately after the BSS of
the main executable, but on amd64 there is a gap as the executable
is loaded very low and valgrind only uses memory below 64Mb when
specifically asked so the heap will go in the first available space
which is at 64Mb:
--11248:1:aspacem <<< SHOW_SEGMENTS: Memory layout at client startup (33 segments, 4 segnames)
--11248:1:aspacem ( 0) /usr/lib64/valgrind/amd64-linux/memcheck
--11248:1:aspacem ( 1) /bin/bash
--11248:1:aspacem ( 2) /lib64/ld-2.4.so
--11248:1:aspacem 0: RSVN 0000000000-00003FFFFF 4194304 ----- SmFixed
--11248:1:aspacem 1: file 0000400000-00004AEFFF 716800 r-x-- d=0xFD00 i=17858591 o=0 (1)
--11248:1:aspacem 2: RSVN 00004AF000-00005ADFFF 1044480 ----- SmFixed
--11248:1:aspacem 3: file 00005AE000-00005B7FFF 40960 rw--- d=0xFD00 i=17858591 o=712704 (1)
--11248:1:aspacem 4: anon 00005B8000-00005BCFFF 20480 rw---
--11248:1:aspacem 5: RSVN 00005BD000-00006B6FFF 1024000 ----- SmFixed
--11248:1:aspacem 6: file 00006B7000-00006BEFFF 32768 rw--- d=0xFD00 i=17858591 o=749568 (1)
--11248:1:aspacem 7: RSVN 00006BF000-0003FFFFFF 57m ----- SmFixed
--11248:1:aspacem 8: anon 0004000000-0004000FFF 4096 rwx--
--11248:1:aspacem 9: RSVN 0004001000-00047FFFFF 8384512 ----- SmLower
--11248:1:aspacem 10: 0004800000-0037FFFFFF 824m
--11248:1:aspacem 11: FILE 0038000000-0038026FFF 159744 r-x-- d=0xFD00 i=6209928 o=0 (0)
--11248:1:aspacem 12: file 0038027000-0038027FFF 4096 r-x-- d=0xFD00 i=6209928 o=159744 (0)
--11248:1:aspacem 13: FILE 0038028000-003815BFFF 1261568 r-x-- d=0xFD00 i=6209928 o=163840 (0)
--11248:1:aspacem 14: 003815C000-003825AFFF 1044480
--11248:1:aspacem 15: FILE 003825B000-003825BFFF 4096 rw--- d=0xFD00 i=6209928 o=1421312 (0)
--11248:1:aspacem 16: ANON 003825C000-0038DFAFFF 11m rw---
--11248:1:aspacem 17: 0038DFB000-0401FFFFFF 15506m
--11248:1:aspacem 18: RSVN 0402000000-0402000FFF 4096 ----- SmFixed
--11248:1:aspacem 19: ANON 0402001000-0402798FFF 7962624 rwx--
--11248:1:aspacem 20: 0402799000-07FE600FFF 16318m
--11248:1:aspacem 21: RSVN 07FE601000-07FEFFDFFF 9m ----- SmUpper
--11248:1:aspacem 22: anon 07FEFFE000-07FF000FFF 12288 rwx--
--11248:1:aspacem 23: 07FF001000-07FFFFFFFF 15m
--11248:1:aspacem 24: RSVN 0800000000-347F0FFFFF 182257m ----- SmFixed
--11248:1:aspacem 25: file 347F100000-347F119FFF 106496 r-x-- d=0xFD00 i=6144028 o=0 (2)
--11248:1:aspacem 26: RSVN 347F11A000-347F218FFF 1044480 ----- SmFixed
--11248:1:aspacem 27: file 347F219000-347F21AFFF 8192 rw--- d=0xFD00 i=6144028 o=102400 (2)
--11248:1:aspacem 28: RSVN 347F21B000-7FFF7A296FFF 130859g ----- SmFixed
--11248:1:aspacem 29: ANON 7FFF7A297000-7FFF7A2ACFFF 90112 rw---
--11248:1:aspacem 30: RSVN 7FFF7A2AD000-FFFFFFFFFF5FFFFF 16383e ----- SmFixed
--11248:1:aspacem 31: ANON FFFFFFFFFF600000-FFFFFFFFFFDFFFFF 8388608 -----
--11248:1:aspacem 32: RSVN FFFFFFFFFFE00000-FFFFFFFFFFFFFFFF 2097152 ----- SmFixed
--11248:1:aspacem >>>
Segments 8 and 9 are the heap (segment 8 is the allocated space and
segment 9 is the reserved space that it will grow into). As you can
see there is a 57Mb gap between the executable and the heap.
> 2. Tweak our program to discover the heap and then disallow maps in the
> region.
>
> We currently assume that the heap follows straight after bss but I don't
> think it does when we are being Valgrinded. Is there anyway to force
> Valgrind to use a particular location for heap?
There is no way to force the heap location except by changing the
source - reducing aspacem_minAddr will cause it to be allocated lower
down, so if it was low enough then the heap would wind up immediately
after the program I guess.
What your doing sounds horribly reliant on current kernel/glibc
behaviour though, even without valgrind... Why do you need to map
at a fixed location rather than just letting the kernel choose an
address for you?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|