Bruce Korb wrote: > SYS_brk(NULL) = 0x00606000 > SYS_brk(0x00627000) = 0x00606000 > SYS_mmap(0, 0x100000, 3, 34, 0xffffffff) = -12
I don't understand this. The brk area contains 132 KiB, and an attempt to mmap 1 MB fails. Where are the remaining 8.9 MB allocated? > test-fprintf-posix3 > linux-vdso.so.1 => (0x00007fffa6fff000) > librt.so.1 => /lib64/librt.so.1 (0x00007f41de2b7000) > libm.so.6 => /lib64/libm.so.6 (0x00007f41de060000) > libc.so.6 => /lib64/libc.so.6 (0x00007f41ddd00000) > libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f41ddae3000) > /lib64/ld-linux-x86-64.so.2 (0x00007f41de4c0000) > test-dprintf-posix2 > linux-vdso.so.1 => (0x00007fff995f9000) > librt.so.1 => /lib64/librt.so.1 (0x00007f9b1dc99000) > libm.so.6 => /lib64/libm.so.6 (0x00007f9b1da42000) > libc.so.6 => /lib64/libc.so.6 (0x00007f9b1d6e2000) > libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f9b1d4c5000) > /lib64/ld-linux-x86-64.so.2 (0x00007f9b1dea2000) > $ size test-fprintf-posix3 test-dprintf-posix2 > text data bss dec hex filename > 15338 648 24 16010 3e8a test-fprintf-posix3 > 15540 648 16 16204 3f4c test-dprintf-posix2 OK, and what about $ size linux-vdso.so.1 $ size /lib64/librt.so.1 $ size /lib64/libm.so.6 $ size /lib64/libpthread.so.0 $ size /lib64/ld-linux-x86-64.so.2 Even more useful would be to put a breakpoint at the malloc(0x88), and while gdb is halting the process, do $ cat /proc/pid/maps Have you by chance enabled 4 MB pages on your system? Bruno
