This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: mprotect() failed: Cannot allocate memory
- From: Peter Zijlstra <peterz at infradead dot org>
- To: PaweÅ Sikora <pluto at agmk dot net>
- Cc: libc-help at sourceware dot org, linux-kernel at vger dot kernel dot org
- Date: Wed, 21 Apr 2010 12:16:50 +0200
- Subject: Re: mprotect() failed: Cannot allocate memory
- References: <201004210105.20942.pluto@agmk.net>
On Wed, 2010-04-21 at 01:05 +0200, PaweÅ Sikora wrote:
> hi,
>
> i'm trying to debug an ugly application with ElectricFence.
> in fact, on x86-64 box with 8GB ram and 16GB swap i'm getting following error:
>
> "ElectricFence Exiting: mprotect() failed: Cannot allocate memory"
>
> the program has been compiled with gcc-4.5, glibc-2.11.1, kernel-2.6.32.
> did you ever come across such (kernel/glibc) limitations?
>
> here's a simple testcase which triggs -ENOMEM in mprotect().
You probably depleted the max map count, see:
/proc/sys/vm/max_map_count
We have a limit on the number of maps you can have, those mprotect()
calls split you maps like crazy, see also /proc/$pid/maps.
eg. change your second test program to include something like:
char buf[128];
snprintf(buf, sizeof(buf), "cat /proc/%d/maps", (int)getpid());
system(buf);
at the end after lowering your NN count to fit, and observe the result
of those mprotect() calls.