Re: strange stack limit behavior when allocating more than 2GB mem on 32bit machine
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
On Fri, 21 Aug 2009 05:47:28 +0200, Joe <longapple@xxxxxxxxx> 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 +-----<mina86@xxxxxxx>----<mina86@xxxxxxxxxx>----ooO--(_)--Ooo-- -- To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html