This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/12232] setrlimit interferes with malloc

Bruce Korb <bkorb at gnu dot org> changed:

           What    |Removed                     |Added
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |

--- Comment #5 from Bruce Korb <bkorb at gnu dot org> 2010-11-18 20:56:08 UTC ---
So, in other words, if you have a process that uses some
10's of K of address space and calls setrlimit to set
it to 10 million bytes, then it is okay for malloc
to fail for a 136 byte allocation?  I think not.

The failure can either be in malloc code or kernel code
and I, as a user space programmer, have no real way to
know if malloc has misused the sbrk()/mmap()/whatever
interface, or if the kernel is mis-responding to those
system calls.  All I know is that I set my address space
size to 10 million bytes in a process that uses no more
than 1 meg of space.  I call malloc(0x88).  I expect
the _first_ call to succeed.  It does not.  There is
no shortage of RAM or swap space.

By the way, after a successful call to malloc, the available
space can then be filled by many calls to malloc.  Presuming that
the first call for 136 bytes did not create a 10 mb arena,
either the first arena was extended or more arenas were
created.  In other words, the malloc usage of sbrk is then

The code referenced in the description should not fail,
given sufficient RAM and swap space.  I have the space.

Configure bugmail:
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]