Getting cannot allocate memory error

I am getting this error in my program...

mprotect: Cannot allocate memory 

ulimit -a gives the output:

core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 20
file size               (blocks, -f) unlimited
pending signals                 (-i) 16382
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) unlimited
virtual memory          (kbyte开发者_运维百科s, -v) unlimited
file locks                      (-x) unlimited

The amount of memory I'm trying to protect is 60 MB. Can someone tell me what is the problem and how it can be solved?

Return Value

On success, mprotect() returns zero.
On error, -1 is returned, and errno is set appropriately.

Errors

EACCES
The memory cannot be given the specified access. This can happen, for example, if
you mmap(2) a file to which you have read-only access, then ask mprotect() to
mark it PROT_WRITE.

EFAULT
The memory cannot be accessed.

EINVAL
addr is not a valid pointer, or not a multiple of PAGESIZE.

ENOMEM
Internal kernel structures could not be allocated.
Or: addresses in the range [addr, addr+len] are invalid for the address space of
the process, or specify one or more pages that are not mapped.

Given the error message, you probably got an ENOMEM error, and looking at the error code, this does not necessarily mean that memory could not be allocated. You might have an invalid address range, or (most likely) you have pages that aren't mapped.

Don't try to protect such a big hunk of memory in one swell foop. Given how virtual memory works, the odds are just too high that some page in that huge chunk will not be mapped. You need to ensure that the page (pages) in question are mapped before calling mprotect.

When you are using system functions it is always a good idea to read the man page on that function. Then re-read it. The man pages can be a bit terse at times.

While I don't think this is your problem here, it should also be noted that mprotect definitely can fail due to allocation failure, for at least two reasons:

1. If permissions are being changed on only part of a VMA, it's necessary for the kernel to split it into two VMAs. This split requires resource allocation, and may fail. (Note that munmap could fail for this same reason, too!)
2. When changing a not-already-dirty page from read-only to writable status, this increases the commit charge for the process. On a system that strictly forbids overcommit, this "allocation" of commit charge can fail when physical memory/swap would be exhausted.