memset 由 shm_openftruncatemmap 分配的大内存区域因总线错误而崩溃。

Question

我有一个演示程序，它使用 shm_open/ftruncate/mmap 来分配内存。

#include <unistd.h>
#include <sys/stat.h>
#include <sys/file.h>
#include <sys/mman.h>
#include <string.h>
#include <errno.h>
#include <stdio.h>
#include <stdlib.h>

void shm_alloc(const char* path, size_t size) {
    int shmfd = shm_open(path, O_CREAT | O_EXCL | O_TRUNC | O_RDWR, 0666);
    if (shmfd == -1) {
        perror("shm_open");
        exit(1);
    }
    printf("shm_open success, path: %s, fd: %d\n", path, shmfd);

    int ret = ftruncate(shmfd, size);
    if (ret != 0) {
        perror("ftruncate");
        exit(1);
    }
    printf("ftruncate success, fd: %d, size: %#lx\n", shmfd, size);

    void* addr = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, shmfd, 0);
    if (addr == MAP_FAILED) {
        perror("mmap");
        exit(1);
    }
    printf("mmap success, fd: %d, size: %#lx, addr: %p\n", shmfd, size, addr);

    close(shmfd);
    memset(addr, 0x00, size); // <===== Crashes here
    printf("memset success, size: %#lx, addr: %p\n", size, addr);
}

int main() {
    shm_alloc("/a", 0x100000000); // 4GB
    shm_alloc("/b", 0x100000000); // 4GB, crashes at the `memset` in this call
    return 0;
}

程序创建了两个4GB的共享内存区 memset 他们。运行程序，它输出以下内容，然后崩溃。

shm_open success, path: /a, fd: 3
ftruncate success, fd: 3, size: 0x100000000
mmap success, fd: 3, size: 0x100000000, addr: 0x7f4c15625000
memset success, size: 0x100000000, addr: 0x7f4c15625000
shm_open success, path: /b, fd: 3
ftruncate success, fd: 3, size: 0x100000000
mmap success, fd: 3, size: 0x100000000, addr: 0x7f4b15625000
[1]    1250849 bus error (core dumped)  ./a.out

如你所见，第一条 memset 成功，而第二次崩溃，我。gdb程式，它显示 第二区 mmap于 0x7f4b15625000 没有足够的空间（4GB）（执行 p (char*)addr + 0xFFFFFFFF 在gdb中产生 Cannot access memory 错误），但它确实有小于4GB的空间（可能是2GB或3GB，我没有测试准确的大小）。.

我运行在Debian 9上，物理内存是16GB，没有交换空间，看来不是内存不够的问题，有谁知道吗？我是不是应该相信 ftruncate/mmap 呼叫？

---

EDIT：运行 df -h 显示了 /dev/shm 是7.8G，所以可能是根本原因。然而，为什么 ftruncate 成功，即使没有足够的空间在 /dev/shm? 为什么当我 ls -alh /dev/shm它显示两个文件 "a "和 "b"，大小都是4.0GB？

的输出 free -h:

# before running the program:
              total        used        free      shared  buff/cache   available
Mem:            15G        701M        9.0G        161M        5.7G         14G
Swap:            0B          0B          0B

# after running the program:
              total        used        free      shared  buff/cache   available
Mem:            15G        702M        1.4G        7.8G         13G        6.6G
Swap:            0B          0B          0B

产出： ulimit -a:

-t: cpu time (seconds)              unlimited
-f: file size (blocks)              unlimited
-d: data seg size (kbytes)          unlimited
-s: stack size (kbytes)             8192
-c: core file size (blocks)         unlimited
-m: resident set size (kbytes)      unlimited
-u: processes                       65535
-n: file descriptors                1024768
-l: locked-in-memory size (kbytes)  64
-v: address space (kbytes)          unlimited
-x: file locks                      unlimited
-i: pending signals                 63053
-q: bytes in POSIX msg queues       819200
-e: max nice                        0
-r: max rt priority                 0
-N 15:                              unlimited

Answer 1

我在16GB的Ubuntu虚拟机上重现了这个问题，默认devshm也有8GB。

在增加 /dev/shm 到9GB，它的工作。

$ ./tm
shm_open success, path: /a, fd: 3
ftruncate success, fd: 3, size: 0x100000000
mmap success, fd: 3, size: 0x100000000, addr: 0x7ff849486000
memset success, size: 0x100000000, addr: 0x7ff849486000
shm_open success, path: /b, fd: 3
ftruncate success, fd: 3, size: 0x100000000
mmap success, fd: 3, size: 0x100000000, addr: 0x7ff749486000
memset success, size: 0x100000000, addr: 0x7ff749486000
$ df /dev/shm -h
Filesystem      Size  Used Avail Use% Mounted on
tmpfs           9.0G  8.1G  1.0G  89% /dev/shm
$ 

我无法回答关于devshm中ftruncate和文件大小的问题，但它可以工作。