【发布时间】：2018-06-13 15:35:12
【问题描述】：
我的 valgrind 出于某种原因没有打印行号和发生错误的文件。这发生在 Linux Ubuntu 16.04.4 发行版中。
这是我的测试方法：
/tmp/a.c:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
int main(int argc, char **argv)
{
char *buf = malloc(10);
strcpy(buf, argv[1]);
return 0;
}
我使用以下命令执行了所有操作：cd /tmp && gcc a.c -o hello -fno-stack-protector -fno-builtin -g && valgrind ./hello
$ cd /tmp && gcc a.c -o hello -fno-stack-protector -fno-builtin -g && valgrind ./hello ./hello
==23422== Memcheck, a memory error detector
==23422== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==23422== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==23422== Command: ./hello
==23422==
==23422== Invalid read of size 1
==23422== at 0x4C31047: strcpy (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==23422== by 0x40119C: ??? (in /tmp/hello)
==23422== by 0x4E5A82F: (below main) (libc-start.c:291)
==23422== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==23422==
==23422==
==23422== Process terminating with default action of signal 11 (SIGSEGV)
==23422== Access not within mapped region at address 0x0
==23422== at 0x4C31047: strcpy (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==23422== by 0x40119C: ??? (in /tmp/hello)
==23422== by 0x4E5A82F: (below main) (libc-start.c:291)
==23422== If you believe this happened as a result of a stack
==23422== overflow in your program's main thread (unlikely but
==23422== possible), you can try to increase the size of the
==23422== main thread stack using the --main-stacksize= flag.
==23422== The main thread stack size used in this run was 8388608.
==23422==
==23422== HEAP SUMMARY:
==23422== in use at exit: 10 bytes in 1 blocks
==23422== total heap usage: 1 allocs, 0 frees, 10 bytes allocated
==23422==
==23422== LEAK SUMMARY:
==23422== definitely lost: 0 bytes in 0 blocks
==23422== indirectly lost: 0 bytes in 0 blocks
==23422== possibly lost: 0 bytes in 0 blocks
==23422== still reachable: 10 bytes in 1 blocks
==23422== suppressed: 0 bytes in 0 blocks
==23422== Rerun with --leak-check=full to see details of leaked memory
==23422==
==23422== For counts of detected and suppressed errors, rerun with: -v
==23422== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault (core dumped)
GCC 版本：gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.9)
Valgrind 版本：valgrind-3.11.0
我也尝试下载和编译最新的 valgrind 版本 (valgrind-3.13.0)，但以同样的问题结束。
编辑：
完整日志的输出：
$ valgrind -v --leak-check=full /tmp/a.out
==17717== Memcheck, a memory error detector
==17717== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==17717== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==17717== Command: /tmp/a.out
==17717==
--17717-- Valgrind options:
--17717-- -v
--17717-- --leak-check=full
--17717-- Contents of /proc/version:
--17717-- Linux version 4.4.0-119-generic (buildd@lcy01-amd64-013) (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.9) ) #143-Ubuntu SMP Mon Apr 2 16:08:24 UTC 2018
--17717--
--17717-- Arch and hwcaps: AMD64, LittleEndian, amd64-cx16-rdtscp-sse3-avx
--17717-- Page sizes: currently 4096, max supported 4096
--17717-- Valgrind library directory: /usr/lib/valgrind
--17717-- Reading syms from /tmp/a.out
--17717-- ELF section outside all mapped regions
--17717-- Reading syms from /lib/x86_64-linux-gnu/ld-2.23.so
--17717-- Considering /lib/x86_64-linux-gnu/ld-2.23.so ..
--17717-- .. CRC mismatch (computed aa979a42 wanted 9019bbb7)
--17717-- Considering /usr/lib/debug/lib/x86_64-linux-gnu/ld-2.23.so ..
--17717-- .. CRC is valid
--17717-- Reading syms from /usr/lib/valgrind/memcheck-amd64-linux
--17717-- Considering /usr/lib/valgrind/memcheck-amd64-linux ..
--17717-- .. CRC mismatch (computed eea41ea9 wanted 2009db78)
--17717-- object doesn't have a symbol table
--17717-- object doesn't have a dynamic symbol table
--17717-- Scheduler: using generic scheduler lock implementation.
--17717-- Reading suppressions file: /usr/lib/valgrind/default.supp
==17717== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-17717-by-rajiska-on-???
==17717== embedded gdbserver: writing to /tmp/vgdb-pipe-to-vgdb-from-17717-by-rajiska-on-???
==17717== embedded gdbserver: shared mem /tmp/vgdb-pipe-shared-mem-vgdb-17717-by-rajiska-on-???
==17717==
==17717== TO CONTROL THIS PROCESS USING vgdb (which you probably
==17717== don't want to do, unless you know exactly what you're doing,
==17717== or are doing some strange experiment):
==17717== /usr/lib/valgrind/../../bin/vgdb --pid=17717 ...command...
==17717==
==17717== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==17717== /path/to/gdb /tmp/a.out
==17717== and then give GDB the following command
==17717== target remote | /usr/lib/valgrind/../../bin/vgdb --pid=17717
==17717== --pid is optional if only one valgrind process is running
==17717==
--17717-- REDIR: 0x401cfd0 (ld-linux-x86-64.so.2:strlen) redirected to 0x3809e181 (???)
--17717-- Reading syms from /usr/lib/valgrind/vgpreload_core-amd64-linux.so
--17717-- Considering /usr/lib/valgrind/vgpreload_core-amd64-linux.so ..
--17717-- .. CRC mismatch (computed 2567ccf6 wanted 49420590)
--17717-- object doesn't have a symbol table
--17717-- Reading syms from /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so
--17717-- Considering /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so ..
--17717-- .. CRC mismatch (computed 0e27c9a8 wanted ac585421)
--17717-- object doesn't have a symbol table
==17717== WARNING: new redirection conflicts with existing -- ignoring it
--17717-- old: 0x0401cfd0 (strlen ) R-> (0000.0) 0x3809e181 ???
--17717-- new: 0x0401cfd0 (strlen ) R-> (2007.0) 0x04c31020 strlen
--17717-- REDIR: 0x401b920 (ld-linux-x86-64.so.2:index) redirected to 0x4c30bc0 (index)
--17717-- REDIR: 0x401bb40 (ld-linux-x86-64.so.2:strcmp) redirected to 0x4c320d0 (strcmp)
--17717-- REDIR: 0x401dd30 (ld-linux-x86-64.so.2:mempcpy) redirected to 0x4c35270 (mempcpy)
--17717-- Reading syms from /lib/x86_64-linux-gnu/libc-2.23.so
--17717-- Considering /lib/x86_64-linux-gnu/libc-2.23.so ..
--17717-- .. CRC mismatch (computed 7a8ee3e4 wanted a5190ac4)
--17717-- Considering /usr/lib/debug/lib/x86_64-linux-gnu/libc-2.23.so ..
--17717-- .. CRC is valid
--17717-- REDIR: 0x4ec9a00 (libc.so.6:strcasecmp) redirected to 0x4a286f0 (_vgnU_ifunc_wrapper)
--17717-- REDIR: 0x4ec5280 (libc.so.6:strcspn) redirected to 0x4a286f0 (_vgnU_ifunc_wrapper)
--17717-- REDIR: 0x4ecbcf0 (libc.so.6:strncasecmp) redirected to 0x4a286f0 (_vgnU_ifunc_wrapper)
--17717-- REDIR: 0x4ec76f0 (libc.so.6:strpbrk) redirected to 0x4a286f0 (_vgnU_ifunc_wrapper)
--17717-- REDIR: 0x4ec7a80 (libc.so.6:strspn) redirected to 0x4a286f0 (_vgnU_ifunc_wrapper)
--17717-- REDIR: 0x4ec914b (libc.so.6:memcpy@GLIBC_2.2.5) redirected to 0x4a286f0 (_vgnU_ifunc_wrapper)
--17717-- REDIR: 0x4ec7400 (libc.so.6:rindex) redirected to 0x4c308a0 (rindex)
--17717-- REDIR: 0x4ebe130 (libc.so.6:malloc) redirected to 0x4c2db20 (malloc)
--17717-- REDIR: 0x4ec5160 (libc.so.6:strcpy) redirected to 0x4a286f0 (_vgnU_ifunc_wrapper)
--17717-- REDIR: 0x4edf9d0 (libc.so.6:__strcpy_sse2_unaligned) redirected to 0x4c31040 (strcpy)
==17717== Invalid read of size 1
==17717== at 0x4C31047: strcpy (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==17717== by 0x40119C: ??? (in /tmp/a.out)
==17717== by 0x4E5A82F: (below main) (libc-start.c:291)
==17717== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==17717==
==17717==
==17717== Process terminating with default action of signal 11 (SIGSEGV)
==17717== Access not within mapped region at address 0x0
==17717== at 0x4C31047: strcpy (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==17717== by 0x40119C: ??? (in /tmp/a.out)
==17717== by 0x4E5A82F: (below main) (libc-start.c:291)
==17717== If you believe this happened as a result of a stack
==17717== overflow in your program's main thread (unlikely but
==17717== possible), you can try to increase the size of the
==17717== main thread stack using the --main-stacksize= flag.
==17717== The main thread stack size used in this run was 8388608.
--17717-- REDIR: 0x4ebe4f0 (libc.so.6:free) redirected to 0x4c2ed80 (free)
==17717==
==17717== HEAP SUMMARY:
==17717== in use at exit: 10 bytes in 1 blocks
==17717== total heap usage: 1 allocs, 0 frees, 10 bytes allocated
==17717==
==17717== Searching for pointers to 1 not-freed blocks
==17717== Checked 62,704 bytes
==17717==
==17717== LEAK SUMMARY:
==17717== definitely lost: 0 bytes in 0 blocks
==17717== indirectly lost: 0 bytes in 0 blocks
==17717== possibly lost: 0 bytes in 0 blocks
==17717== still reachable: 10 bytes in 1 blocks
==17717== suppressed: 0 bytes in 0 blocks
==17717== Reachable blocks (those to which a pointer was found) are not shown.
==17717== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==17717==
==17717== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
==17717==
==17717== 1 errors in context 1 of 1:
==17717== Invalid read of size 1
==17717== at 0x4C31047: strcpy (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==17717== by 0x40119C: ??? (in /tmp/a.out)
==17717== by 0x4E5A82F: (below main) (libc-start.c:291)
==17717== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==17717==
==17717== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault (core dumped)
编辑 2：在 Docker 系统下测试在我的系统上编译的二进制文件后，问题似乎是相同的，这导致认为问题出在二进制文件本身上。用 Docker 系统的 GCC 编译可以很好地使用 valgrind。
编辑 3：刚刚编译了最新的 GCC 版本（8.1.0）并尝试用它编译程序：同样的问题。此外，您可能需要注意 valgrind 无法解决发生问题的函数，即使可执行文件没有条带化。
此外，在valgrind -v 命令中，我们可以在读取可执行文件的符号时看到注释ELF section outside all mapped regions。
我有点迷路了，看起来它既不是来自 GCC 也不是来自 Valgrind。也许某种系统配置？
【问题讨论】：
-
您真的在运行您认为正在运行的程序吗？你的当前目录是
/tmp吗？如果你只是这样做怎么办？valgrind ./a.out那么会发生什么？ -
不幸的是，是的。 Valgrind 确认文件的路径。使用
./a.out运行时找不到文件。我什至尝试设置 GCC 的-o文件以将名称设置为其他名称并在其上调用 valgrind，同样的问题。 -
如果您执行
gcc a.c -g并随后执行valgrind ./a.out并收到 Valgrind 找不到您的程序的错误消息是高度可疑的。请编辑您的问题以包含您用于构建和运行 Valgrind 的 exact 命令，包括您正在执行此操作的路径。 -
@Someprogrammerdude 这实际上是可疑的。刚刚用完整的输出编辑了命令。几周前，我拥有完整的 Ubuntu 桌面，但不得不重新下载所有 Ubuntu 基础包。也许 valgrind / gcc 需要一些我没有重新下载的其他包？
-
只是添加了一些细节，它似乎不是来自 GCC 也不是 Valgrind 本身。但是在它编译的时候肯定发生了一些事情。
标签： c debugging ubuntu-16.04 valgrind