mmap使用shm_open文件對象返回ENOMEM

Question

在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（內存，長度，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

我希望這是一個簡單的:)

Answer 1

好吧，我發現前幾天是我的問題。 我誤讀了mmap的文檔，其中說mmap返回基於第一個參數（在我的情況下為先前映射的地址）的映射，並且結果由實現定義。 我認為這是mmap可能會為我重新映射以前的映射的建議，但是事實並非如此。 如果我使用了MAP_FIXED標志，則可能只有這種情況，但是我避免了這種情況，因為文檔建議使用它。 無論如何，在創建新映射之前，必須使用munmap刪除先前的映射。 我希望這篇文章能幫助任何與我一樣愚蠢的誤讀的人