Re: strange stack limit behavior when allocating more than 2GB mem on 32bit machine
Michał Nazarewicz <[email protected]>
| Newsgroups | org.kernel.vger.linux-c-programming |
|---|---|
| Message-ID | <[email protected]> |
On Fri, 21 Aug 2009 05:47:28 +0200, Joe <[email protected]> wrote: > Here I encounter something which I can't understand. > What I want to do is to allocate ~2.5GB mem, it fails when stack limit > is unlimited, but succeeded when stack limit is 10240. I cannot really answer your question but maybe this will give you some more insight: > $ free -m > total used free shared buffers cached > Mem: 2024 1996 28 0 30 1401 > -/+ buffers/cache: 563 1461 > Swap: 10236 0 10236 > $ ulimit -s > 10240 > $ ./malloc 2500 > Malloc succeeded <======= succeeds when stack limit is 10240 > $ ulimit -s unlimited > $ ./malloc 2500 > malloc failed: Cannot allocate memory <======== fails when stack > limit is unlimited??? On 32-bit system, in standard configuration, user space programs can address up to 3GiB of RAM (the other 1GiB is reserved for kernel). It's possible that with unlimited stack Linux reserves more address space for stack leaving less for heap -- this may cause malloc(3) to fail. > BTW, there is no such problem on 64bit machine On 64-bit system, the 3GiB address space limit described above does not exist and thus, if I'm correct, the program will succeed. BTW. By default Linux does not allocate memory when calling malloc(3) (sbrk(2) in fact). The pages are allocated when they are first referenced. This means, that even though malloc(3) returns non-NULL you may have no access to the allocated area -- ie. program will segfault trying to access it. Yes, this is in violation of the C standard. -- Best regards, _ _ .o. | Liege of Serenly Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Micha³ "mina86" Nazarewicz (o o) ooo +-----<[email protected]>----<[email protected]>----ooO--(_)--Ooo-- -- To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html