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: Bruce Korb
Subject: Re: done digging around test-dprintf-posix2
Date: Sun, 09 Jan 2011 17:40:02 -0800
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20101125 SUSE/3.0.11 Thunderbird/3.0.11

On 01/09/11 13:15, Bastien ROUCARIES wrote:
>> 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

Given that the process is only at 300K, and that the system itself
is largely idle, that looks like the kernel is giving a bad answer
for the first result.

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

With or without swap space mapped, the address space has been
constrained to 10MB.  malloc() may not know that, but the kernel
does.  That *should* cause these 64MB and 128MB allocations to
fail.  If it is these failures that are causing malloc to fail,
then that leans toward a glibc bug.

As I think I mentioned before, this is not my bailiwick.



reply via email to

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