bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: done digging around test-dprintf-posix2


From: Bastien ROUCARIES
Subject: Re: done digging around test-dprintf-posix2
Date: Mon, 10 Jan 2011 08:34:29 +0100

On Sun, Jan 9, 2011 at 10:44 PM, Bruno Haible <address@hidden> wrote:
> 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,

For me brk is failling ....
> 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

I do not think linux vdso is taken in account (or it is a bug). It is
a kernel page, so not accounted in process memory

Bastien

> 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
>
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]