This problem is discovered when the purpose of the test item is effective. Each object is allocated a page of space and then protected by mprotect, this problem occurs when the system allocates more than pages.
Google has mentioned this issue in a mailing list. https://sourceware.org/ml/libc-help/2010-04/msg00026.html
The excerpt is as follows:
Bytes ----------------------------------------------------------------------------------------------------------------------
On wed, 2010-04-21 at + 0200, pawe? Sikora wrote:
> Hi,
>
> I'm trying to debug an uugly application with your icfence.
> In fact, on x86-64 box with 8 gb ram and 16 GB swap I'm getting following error:
>
> "Maid () 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 into your SS 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 ()
Callsplit 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 () CILS.
Yes, that is the clue :)
The limit in/proc/sys/Vm/max_map_count was set to 65530.
With 'echo 128000>/proc/sys/Vm/max_map_count 'The testcase passes.
Bytes ----------------------------------------------------------------------------------------------------------------------
Therefore, the solution is to set/proc/sys/Vm/max_map_count to a larger value.
View the max_map_count value:
more /proc/sys/vm/max_map_count
VM. max_map_count = 128000 directly written to/etc/sysctl. conf,
Then execute
sysctl -p
Or directly execute
echo 128000 > /proc/sys/vm/max_map_count
OK. The problem is solved here. To sum up the reasons:
The proc file system provides you with a lot of kernel information help, allowing you to improve system performance by modifying kernel parameters.
Certificate -----------------------------------------------------------------------------------------------------------------------------------------------------
[Email protected]:/proc/sys/Vm $ ls
Block_dump legacy_va_layout oom_dump_tasks
Compact_memory lowmem_reserve_ratio oom_kill_allocating_task
Dirty_background_bytes max_map_count overcommit_memory
Dirty_background_ratio memory_failure_early_kill overcommit_ratio
Dirty_bytes memory_failure_recovery page-Cluster
Dirty_expire_centisecs min_free_kbytes panic_on_oom
Dirty_ratio min_slab_ratio percpu_pagelist_fraction
Dirty_writeback_centisecs min_unmapped_ratio scan_unevictable_pages
Drop_caches mmap_min_addr stat_interval
Extfrag_threshold nr_hugepages swappiness
Extra_free_kbytes nr_hugepages_mempolicy vfs_cache_pressure
Hugepages_treat_as_movable nr_overcommit_hugepages would_have_oomkilled
Hugetlb_shm_group nr_pdflush_threads zone_reclaim_mode
Laptop_mode numa_zonelist_order
---------------------------------------------------------------------------------
/Proc/sys/Vm for information on each file, see http://www.linuxinsight.com/proc_sys_vm_hierarchy.html
Max_map_count: This file contains the maximum number of memory map areas a process may have. memory Map areas are used as a side-effect of calling malloc, directly by MMAP and mprotect, and also when loading shared libraries. while most applications need less than a thousand maps, certain programs, fig, may consume lots of them, e.g ., up to one or two maps per allocation. the default value is 65536.
Mprotect () failed: cannot allocate memory
