mmap使用shm_open文件对象返回ENOMEM

时间:2012-01-19 20:11:23

标签: linux shared-memory mmap enomem

在linux中尝试使用shm_open并遇到问题。我经常使用ftrunc调整共享内存段的大小,并使用mmap重新映射调整大小的段。然而,在20兆字左右,我从mmap获得了ENOMEM。

我试图解决问题的方法:

首先,我发现了这些sysctl参数。我重新配置了它们:

kernel.shmmax = 268435456
kernel.shmall = 2097152

(页面中指定了shmall)

此后问题仍然存在。调查导致问题的调整大小的细节显示,调用ftrunc调用共享内存对象的调用成功(/ dev / shm中的相应文件具有所请求的新大小)。

来自http://pubs.opengroup.org/onlinepubs/009695399/functions/mmap.html

文档提出了ENOMEM错误的三个可能原因:


[ENOMEM] 指定了MAP_FIXED,范围[addr,addr + len]超出了进程地址空间允许的范围;或者,如果未指定MAP_FIXED且地址空间中没有足够的空间来实现映射。

[ENOMEM] [ML] [Option Start]如果mlockall()需要,映射无法锁定在内存中,因为它需要比系统能够提供的空间更多的空间。 [选项结束]

[ENOMEM] [TYM] [Option Start]没有足够的未分配内存资源保留在由fildes指定的类型化内存对象中以分配len个字节。 [选项结束]


我没有使用MAP_FIXED或锁定,并且/ dev / shm中图像的大小表明第三个原因不是问题。我的mmap调用如下所示:

mmap(mem,length,PROT_READ | PROT_WRITE,MAP_SHARED,fd,0)

其中mem最初为0,此后指的是成功映射的最后一个地址mmap。

我发现信息表明ulimit设置可能会将内存限制为单个进程,但我不认为问题出在这里。以防万一,ulimit -a在我的机器上看起来像这样:

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) 65536
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          (kbytes, -v) unlimited
file locks                      (-x) unlimited

我希望这很容易:)

1 个答案:

答案 0 :(得分:1)

好吧,我前几天发现了我的问题。我误读了mmap的文档,其中mmap返回基于第一个参数(在我的情况下是先前映射的地址)的映射,结果由实现定义。我把这作为一个建议,mmap可能会为我重新映射我之前的映射,但事实并非如此。如果我使用了MAP_FIXED标志,可能只是这种情况,但我避免了这种情况,因为文档建议不要使用它。无论如何,在创建新映射之前,必须使用munmap删除先前的映射。我希望这篇文章能帮助任何人做出与我一样的愚蠢误读