使用mmap/munmap时遇到问题-在执行783次迭代后出现总线错误？

Question

使用mmap/munmap时遇到问题-在执行783次迭代后出现总线错误？

5

好的，这是情况说明：我在高性能计算(HPC)领域工作，我们正在准备扩展到数万个节点。为应对这个问题，我实现了一个本地进程，它会缓存每个节点上的信息，以减少网络流量。然后通过共享内存公开此信息。基本逻辑是有一个众所周知的共享内存块，其中包含当前已缓存表的名称。当更新发生时，缓存工具创建一个新的共享内存表，填充它，然后使用新表的名称更新众所周知的块。

代码似乎运行良好(例如valgrind没有内存泄漏)，但当我故意进行压力测试时，前783次更新完全正常——但在第784次时，在尝试写入映射内存时出现了SIGBUS错误。

如果问题是打开太多文件(因为我泄漏了文件描述符)，我期望shm_open()会失败。如果问题是我泄漏了映射内存，我期望mmap()会失败或valgrind会报告泄漏。

以下是代码片段。有人能提供建议吗？

int
initialize_paths(writer_t *w, unsigned max_paths)
{
int err = 0;
reader_t *r = &(w->unpublished);

close_table(r,PATH_TABLE);

w->max_paths = max_paths;

err = open_table(r, PATH_TABLE, O_RDWR | O_CREAT, max_paths, 0);

return err;
}

static void
close_table(reader_t *r, int table)
{
    if (r->path_table && r->path_table != MAP_FAILED) {
       munmap(r->path_table,r->path_table->size);
       r->path_table=NULL;
    }
    if (r->path_fd>0) { close(r->path_fd); r->path_fd=0; }
}


static int
open_table(op_ppath_reader_t *r, int table, int rw, unsigned c, unsigned c2)
{
// Code omitted for clarity
if (rw & O_CREAT) {
    prot = PROT_READ | PROT_WRITE;
} else {
    // Note that this overrides the sizes set above.
    // We will get the real sizes from the header.
    prot = PROT_READ;
    size1 = sizeof(op_ppath_header_t);
    size2 = 0;
}

fd = shm_open(name, rw, 0644);
if (fd < 0) {
    _DBG_ERROR("Failed to open %s\n",name);
    goto error;
}

if (rw & O_CREAT) {
    /* Create the file at the specified size. */
    if (ftruncate(fd, size1 + size2)) {
        _DBG_ERROR("Unable to size %s\n",name);
        goto error;
    }
}

h = (op_ppath_header_t*)mmap(0, size1 + size2, prot, MAP_SHARED, fd, 0);
if (h == MAP_FAILED) {
    _DBG_ERROR("Unable to map %s\n",name);
    goto error;
}

if (rw & O_CREAT) {
    /*
     * clear the table & set the maximum lengths.
     */
    memset((char*)h,0,size1+size2);  -- SIGBUS OCCURS HERE
    h->s1 = size1;
    h->s2 = size2;
} else {
// more code omitted for clarity.
}

更新：

以下是一次失败的样本调试输出：

NOTICE: Pass 783: Inserting records.
NOTICE: Creating the path table.
TRC: initialize_paths[
TRC: close_table[
TRC: close_table]
TRC: open_table[
DBG: h=0x0x2a956b2000, size1=2621536, size2=0

以下是来自前一个迭代的相同输出:

NOTICE: Pass 782: Inserting records.
NOTICE: Creating the path table.
TRC: initialize_paths[
TRC: close_table[
TRC: close_table]
TRC: open_ppath_table[
DBG: h=0x0x2a956b2000, size1=2621536, size2=0
TRC: open_ppath_table]
TRC: op_ppath_initialize_paths]

请注意指针地址是有效的，大小也是有效的。

GDB报告崩溃的方式如下：

Program received signal SIGBUS, Bus error.
[Switching to Thread 182895447776 (LWP 5328)]
0x00000034a9371d20 in memset () from /lib64/tls/libc.so.6
(gdb) where
#0  0x00000034a9371d20 in memset () from /lib64/tls/libc.so.6
#1  0x0000002a955949d0 in open_table (r=0x7fbffff188, table=1, rw=66,
c=32768, c2=0) at ofedplus_path_private.c:294
#2  0x0000002a95595280 in initialize_paths (w=0x7fbffff130,
    max_paths=32768) at path_private.c:567
#3  0x0000000000402050 in server (fname=0x7fbffff270 "gidtable", n=10000)
    at opp_cache_test.c:202
#4  0x0000000000403086 in main (argc=6, argv=0x7fbffff568)
    at opp_cache_test.c:542

(gdb)

即使删掉了memset，在下一行设置h->size1时仍然会导致SIGBUS错误 - 而size1是映射区域的前4个字节。

- Mike Heinz

O_CREAT情况下，size1和size2的值是多少？ - Nikolai Fetissov

你能否使用gdb进行压力测试这段代码（例如在批处理模式下），在memset调用之前设置断点以打印h的值，然后继续执行吗？如果在gdb中运行正常，很可能是内存泄漏/缓冲区溢出问题。 - Shirkrin

在这种情况下，size1大约为256k。对于压力测试，它始终是相同的大小。 - Mike Heinz

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Shirkrin · Accepted Answer

可能由于对SHM对象的引用过多导致SIGBUS错误。
从您上面的代码来看，您使用了shm_open()、mmap()、munmap()，但是您缺少了shm_unlink()。
正如*shm_open/shm_close的manpage所述，这些对象是引用计数的。

shm_unlink的操作类似于unlink(2)：它删除一个共享内存对象的名称，并在所有进程取消映射该对象后，释放和销毁相关内存区域的内容。
成功执行shm_unlink后，尝试使用相同名称的shm_open对象将失败（除非指定了O_CREAT，在这种情况下将创建一个新的不同对象）。

也许这些信息能帮助解决您的问题。