Question

首先，我想道歉，因为无法缩小问题范围，无法分享重现错误的短程序。

外部库（FUSE）调用strncpy“随机”覆盖我的代码中的shared_ptr<mutex>，当我尝试锁定该互斥锁时会导致段错误。我用valgrind运行我的程序，它没有捕获任何内存错误（下面的valgrind标志）。当我在gdb中运行我的代码并在shared_ptr上设置一个观察点时，它会中断对strncpy的调用。 gdb说所有strncpy的参数（dest，src和nbytes）都已经“优化了”，这让我觉得它正在使用未初始化的内存进行该调用。我能正确地解释这个吗？知道原因是什么吗？

这是指针被覆盖时gdb的堆栈跟踪：

#0  __strncpy_ssse3 () at ../sysdeps/x86_64/multiarch/strcpy-ssse3.S:2482
#1  0x0000003245809094 in strncpy (__len=<optimized out>, __src=<optimized out>, __dest=<optimized out>) at /usr/include/bits/string3.h:120
#2  add_name (buf=<optimized out>, bufsize=<optimized out>, s=<optimized out>, name=<optimized out>) at fuse.c:907
#3  0x000000324580997c in try_get_path (f=<optimized out>, nodeid=<optimized out>, name=<optimized out>, path=<optimized out>, wnodep=<optimized out>, need_lock=<optimized out>) at fuse.c:956
#4  0x000000324580a281 in get_path_common (f=<optimized out>, nodeid=<optimized out>, name=<optimized out>, path=<optimized out>, wnode=<optimized out>) at fuse.c:1152
#5  0x0000003245812432 in fuse_lib_unlink (req=<optimized out>, parent=<optimized out>, name=<optimized out>) at fuse.c:1198
#6  0x0000003245817057 in fuse_ll_process_buf (data=0x6f5650, buf=0x7fffffffd850, ch=<optimized out>) at fuse_lowlevel.c:2441
#7  0x000000324581388f in fuse_session_loop (se=0x6f8410) at fuse_loop.c:40
#8  0x000000324580b698 in fuse_loop (f=<optimized out>) at fuse.c:4309
#9  0x000000324581bb8f in fuse_main_common (argc=<optimized out>, argv=<optimized out>, op=<optimized out>, op_size=<optimized out>, user_data=<optimized out>, compat=<optimized out>) at helper.c:355
#10 0x000000000046f1b6 in main (argc=4, argv=0x7fffffffdec8) at ../src/fuse.cpp:100

以下是我与valgrind合作的论据：

valgrind --tool=memcheck --leak-check=yes --show-reachable=yes --num-callers=20 --track-fds=yes

Answer 1

此错误是使用shared_ptr创建new，然后将其版式转换为weak_ptr并删除它的结果。

Answer 2

gdb说所有strncpy的参数（dest，src和nbytes）都已经“优化出来”，这让我觉得它正在为该调用使用未初始化的内存。我能正确地解释这个吗？

没有。这只意味着优化器已经删除了一些函数序言样板，它允许调试器可靠地打印函数的参数。在任何合理的优化级别下，这对于简单的函数非常常见。

这是一个简单的例子：

int
mystrcpy(char *p, const char *q)
{
    while (*p++ = *q++);
}

使用-g -O0编译，你会看到它立即将其参数溢出到堆栈中：

mystrcpy:
.LFB0:
        .file 1 "t.c"
        .loc 1 5 0
        .cfi_startproc
        pushq   %rbp
        .cfi_def_cfa_offset 16
        movq    %rsp, %rbp
        .cfi_offset 6, -16
        .cfi_def_cfa_register 6
        movq    %rdi, -8(%rbp)      <<< here
        movq    %rsi, -16(%rbp)     <<< and here
        ...

然后编译器生成了关于它的调试信息：

    .section        .debug_info
    ...
    .uleb128 0x7
    .string "p"   <<< from char *p
    .byte   0x1
    .byte   0x4
    .long   0x65
    .byte   0x2
    .byte   0x91
    .sleb128 -24  <<< not 100% sure but this is probably related to frame offset
    .uleb128 0x7
    .string "q"
    .byte   0x1
    .byte   0x4
    .long   0x72
    .byte   0x2
    .byte   0x91
    .sleb128 -32   <<< note adjacent to p

当你加速-O2 -g时，尽管-g功能变得更小：

mystrcpy:
.LFB11:
        .file 1 "t.c"
        .loc 1 5 0
        .cfi_startproc
        (at this point we start copying, using the input regs directly)

现在调试信息中没有p或q的引用。从这个例子中可以看出，您可以在寄存器中找到所需的信息，但是您必须反汇编并理解解释它们的函数。如果你的函数调用了其他函数，你可能必须找到寄存器溢出到堆栈的位置（对于callee-save regs来说可能相当远）。

C ++ strncpy参数“优化出来”;覆盖随机记忆

2 个答案: