Re: done digging around test-dprintf-posix2

[Bastien ROUCARIES]

On Sun, Jan 9, 2011 at 7:46 PM, Bruce Korb <address@hidden> wrote:
> Hi Bruno,
>
> ..............
> __libc_start_main(0x4009c0, 2, 0x7fff27c151e8, 0x4036d0, 0x403760 <unfinished
> ...>
> getrlimit(2, 0x7fff27c150e0, 0x7fff27c15200, 0x7f2965bfe4a8, 0x7f2965bff320
> <unfinished ...>
> SYS_getrlimit(2, 0x7fff27c150e0)                 = 0
> <... getrlimit resumed> )                        = 0
> setrlimit(2, 0x7fff27c150e0, 0x7fff27c15200, -1, 0x7f2965bff320 <unfinished
> ...>
> SYS_setrlimit(2, 0x7fff27c150e0)                 = 0
> <... setrlimit resumed> )                        = 0
> getrlimit(9, 0x7fff27c150e0, 0x7fff27c15200, -1, 0x7f2965bff320 <unfinished
> ...>
> SYS_getrlimit(9, 0x7fff27c150e0)                 = 0
> <... getrlimit resumed> )                        = 0
> setrlimit(9, 0x7fff27c150e0, 0x7fff27c15200, -1, 0x7f2965bff320 <unfinished
> ...>
> SYS_setrlimit(9, 0x7fff27c150e0)                 = 0
> <... setrlimit resumed> )                        = 0
> strtol(0x7fff27c17263, 0, 10, -1, 0x7f2965bff320) = 1
> malloc(88 <unfinished ...>
> SYS_brk(NULL)                                    = 0x00606000
> SYS_brk(0x00627000)                              = 0x00606000
> SYS_mmap(0, 0x100000, 3, 34, 0xffffffff)         = -12
> SYS_mmap(0, 0x8000000, 0, 16418, 0xffffffff)     = -12
> SYS_mmap(0, 0x4000000, 0, 16418, 0xffffffff)     = -12
> SYS_mmap(0, 0x8000000, 0, 16418, 0xffffffff)     = -12
> SYS_mmap(0, 0x4000000, 0, 16418, 0xffffffff)     = -12
> <... malloc resumed> )                           = NULL
> __errno_location()                               = 0x7f29662506a8
> __errno_location()                               = 0x7f29662506a8
> SYS_exit_group(1 <no return ...>
>
> RE: SYS_mmap()
> I have no idea what "-12" means.   It doesn't mean "a-ok" and it
> isn't "-1".  ltrace does not seem to recognize it as an error
> result, so it isn't printing the location of the error code
> (which wouldn't help anyway).


I mean ENOMEM, linux kernel return error as -errno (see asm for i386)

Kernel answer out of memory

>
> Anyhow, I *think* the first mmap ought to succeed because the
> process size is about 300K and it is only asking for 1M more.
> That fits my recollection of the malloc code.  The remaining
> mmap calls are rather over the top and I'd expect them to be rejected.
> I would not expect malloc to try to allocate so much space.
> But maybe there is special magic there since the request is for "no access".
> It is mapped PRIVATE/ANONYMOUS like the first map. I don't know what
> the 0x4000 protection bit means.

MAP_NORESERVE  :
Do not reserve swap space for this mapping. When swap space is
reserved, one has the guarantee that it is possible to modify the
mapping. When swap space is not reserved one might get SIGSEGV upon a
write if no physical memory is available. See also the discussion of
the file /proc/sys/vm/overcommit_memory in proc(5). In kernels before
2.6, this flag only had effect for private writable mappings.

> SUMMARY: there is brokenness somewhere between glibc and the kernel.
> From the perspective of gnulib tests, it doesn't matter where the
> fault lies, it matters that there is a problem.  What precise confluence
> of circumstances triggers the problem doesn't seem crucial to me,
> either, except to the glibc/kernel folks who do need to chase down
> the exact cause.  Therefore, I think the test code should evade the
> problem rather than continuing to fail, leaving the fix to others.
> This, as a stand alone, not-linked-to-libposix, program does not fail
> (well, I've not seen it fail):

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

Bastien