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
