Re: done digging around test-dprintf-posix2

[Bruce Korb]

On 01/09/11 13:44, Bruno Haible 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,
> and an attempt to mmap 1 MB fails. Where are the remaining 8.9 MB
> allocated?
> 

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

Reverse order:

1. 4MB pages -- don't know, but I doubt it.  This is an out-of-the-box
   openSuSE 11.3 installation for x86-64.  I forget how to detect it.
   Too long ago.

2. I do not think I need those sizes, since I have a core image.
   That core image is just under 300K.  Remember, I replaced the
   "return 1" statement in main() with "abort()" and got the core.
   Want it?  http://autogen.sourceforge.net/data
   The failing fully linked executable is there, too, provided
   you have the same glibc on x86-64:
>  $ /lib64/libc.so.6 | head -1
>  GNU C Library stable release version 2.11.2 (20100531), by Roland McGrath et 
> al.
   Anyway:
>  $ size data/*.core
>    text    data     bss     dec     hex filename
>   65536  225280       0  290816   47000 data/dprintf-posix2.core \
>    (core file invoked as ./test-dprintf-posix2 1)

3. size: 'linux-vdso.so.1': No such file --- I see "ldd" listed it,
   but it beats heck out of me where it is.  I did a find:
     $ find /lib /lib64 ~gnu/proj/gnulib/libposix -name 'linux-vdso*'
   but there were no results.  The other libs:

     text    data     bss     dec     hex filename
    28557    1268    2448   32273    7e11 /lib64/librt.so.1
   350636     668      72  351376   55c90 /lib64/libm.so.6
    93130    1680   16672  111482   1b37a /lib64/libpthread.so.0
   122859    5076     424  128359   1f567 /lib64/ld-linux-x86-64.so.2

   If "libm" gets pulled in in a lazy fashion, then it won't get
   pulled in.  It is not used for this program.

4. Finally:  ``I don't understand this.''
   I don't either.  That's why my recommendation is to hand it off
   to the malloc folks for some help.  They might be completely
   correct that this is a kernel problem.  It even seems somewhat
   likely to me at this point.  But I use weasel words like "likely"
   because the glibc/kernel interaction is not exactly my bailiwick.
   I can eventually dig through it, but others more familiar with
   the issue can surely isolate the problem more easily than I can.
   I have tried to step into glibc and it is a really ugly, twisty
   maze -- especially since I cannot easily rebuild it.  I tried
   once and wound up having to re-install.  I am shy now.  (No, I
   did not replace /lib/libc.so.6, I do not remember precisely
   what happened -- it was a decade ago.)

5. Oh, wait:
>  glibc does not try enouth to allocate memory. We should contact
>  http://www.eglibc.org/ mainteners that are more willing to help
>  concerning this kind of problem.
   They might be more interested if it can be reproduced using
   their variation of glibc.  I don't have a platform for that and
   remember:  this does not always happen.  (That would be too easy.)
   That is my guess anyway.

Thanks to all who spend any time digging through this.....

Regards, Bruce