c++ - valgrind 在主机名命令输出中显示内存泄漏

Question

已关闭。此问题不符合 Stack Overflow guidelines 。目前不接受答案。

---

这个问题似乎不是关于 a specific programming problem, a software algorithm, or software tools primarily used by programmers 。如果您认为这个问题与 another Stack Exchange site 上的主题有关，您可以发表评论来解释问题可能在哪里得到解答。

已关闭 4 年前。

Improve this question

我只是在玩 valgrind，随机决定检查一些 linux 命令的 valgrind 输出。

尝试过ls -lrth效果很好。 definitely lost 中至少没有字节.

但是hostname命令的输出显示了一些我没有预料到的内容，即内存泄漏。

主机名命令有问题还是我遗漏了一些东西。非常感谢您的评论。预先感谢您。

==19877== Memcheck, a memory error detector
==19877== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==19877== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==19877== Command: hostname
==19877== 
--19877-- Valgrind options:
--19877--    --leak-check=full
--19877--    --show-leak-kinds=all
--19877--    --track-origins=yes
--19877--    --verbose
--19877-- Contents of /proc/version:
--19877--   Linux version 3.10.0-957.1.3.el7.x86_64 (mockbuild@kbuilder.bsys.centos.org) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC) ) #1 SMP Thu Nov 29 14:49:43 UTC 2018
--19877-- 
--19877-- Arch and hwcaps: AMD64, LittleEndian, amd64-cx16-lzcnt-rdtscp-sse3-avx-avx2-bmi
--19877-- Page sizes: currently 4096, max supported 4096
--19877-- Valgrind library directory: /usr/lib64/valgrind
--19877-- Reading syms from /usr/bin/hostname
--19877--    object doesn't have a symbol table
--19877-- Reading syms from /usr/lib64/ld-2.17.so
--19877-- Reading syms from /usr/lib64/valgrind/memcheck-amd64-linux
--19877--    object doesn't have a symbol table
--19877--    object doesn't have a dynamic symbol table
--19877-- Scheduler: using generic scheduler lock implementation.
--19877-- Reading suppressions file: /usr/lib64/valgrind/default.supp
==19877== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-19877-by-compuser-on-lenovoe470.localdomain
==19877== embedded gdbserver: writing to   /tmp/vgdb-pipe-to-vgdb-from-19877-by-compuser-on-lenovoe470.localdomain
==19877== embedded gdbserver: shared mem   /tmp/vgdb-pipe-shared-mem-vgdb-19877-by-compuser-on-lenovoe470.localdomain
==19877== 
==19877== TO CONTROL THIS PROCESS USING vgdb (which you probably
==19877== don't want to do, unless you know exactly what you're doing,
==19877== or are doing some strange experiment):
==19877==   /usr/lib64/valgrind/../../bin/vgdb --pid=19877 ...command...
==19877== 
==19877== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==19877==   /path/to/gdb hostname
==19877== and then give GDB the following command
==19877==   target remote | /usr/lib64/valgrind/../../bin/vgdb --pid=19877
==19877== --pid is optional if only one valgrind process is running
==19877== 
--19877-- REDIR: 0x4019d70 (ld-linux-x86-64.so.2:strlen) redirected to 0x58059dd1 (???)
--19877-- REDIR: 0x4019b40 (ld-linux-x86-64.so.2:index) redirected to 0x58059deb (???)
--19877-- Reading syms from /usr/lib64/valgrind/vgpreload_core-amd64-linux.so
--19877-- Reading syms from /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so
==19877== WARNING: new redirection conflicts with existing -- ignoring it
--19877--     old: 0x04019d70 (strlen              ) R-> (0000.0) 0x58059dd1 ???
--19877--     new: 0x04019d70 (strlen              ) R-> (2007.0) 0x04c2ca70 strlen
--19877-- REDIR: 0x4019cf0 (ld-linux-x86-64.so.2:strcmp) redirected to 0x4c2dbc0 (strcmp)
--19877-- REDIR: 0x401a9b0 (ld-linux-x86-64.so.2:mempcpy) redirected to 0x4c30c40 (mempcpy)
--19877-- Reading syms from /usr/lib64/libnsl-2.17.so
--19877-- Reading syms from /usr/lib64/libc-2.17.so
--19877-- REDIR: 0x50df700 (libc.so.6:strcasecmp) redirected to 0x4a24740 (_vgnU_ifunc_wrapper)
--19877-- REDIR: 0x50dc480 (libc.so.6:strnlen) redirected to 0x4a24740 (_vgnU_ifunc_wrapper)
--19877-- REDIR: 0x50e19d0 (libc.so.6:strncasecmp) redirected to 0x4a24740 (_vgnU_ifunc_wrapper)
--19877-- REDIR: 0x50deee0 (libc.so.6:memset) redirected to 0x4a24740 (_vgnU_ifunc_wrapper)
--19877-- REDIR: 0x50dee90 (libc.so.6:memcpy@GLIBC_2.2.5) redirected to 0x4a24740 (_vgnU_ifunc_wrapper)
--19877-- REDIR: 0x50dde70 (libc.so.6:__GI_strrchr) redirected to 0x4c2c430 (__GI_strrchr)
--19877-- REDIR: 0x50dde30 (libc.so.6:rindex) redirected to 0x4a24740 (_vgnU_ifunc_wrapper)
--19877-- REDIR: 0x518fd90 (libc.so.6:__strrchr_sse42) redirected to 0x4c2c4c0 (__strrchr_sse42)
--19877-- REDIR: 0x50da900 (libc.so.6:strcmp) redirected to 0x4a24740 (_vgnU_ifunc_wrapper)
--19877-- REDIR: 0x518e000 (libc.so.6:__strcmp_sse42) redirected to 0x4c2db70 (__strcmp_sse42)
--19877-- REDIR: 0x50dc3a0 (libc.so.6:__GI_strlen) redirected to 0x4c2c9d0 (__GI_strlen)
--19877-- REDIR: 0x50d5160 (libc.so.6:malloc) redirected to 0x4c29b3c (malloc)
--19877-- REDIR: 0x50e4110 (libc.so.6:__GI_memcpy) redirected to 0x4c2e560 (__GI_memcpy)
--19877-- REDIR: 0x50de570 (libc.so.6:memchr) redirected to 0x4c2dc60 (memchr)
lenovoe470.localdomain
--19877-- REDIR: 0x50d5580 (libc.so.6:free) redirected to 0x4c2ac36 (free)
==19877== 
==19877== HEAP SUMMARY:
==19877==     in use at exit: 128 bytes in 1 blocks
==19877==   total heap usage: 1 allocs, 0 frees, 128 bytes allocated
==19877== 
==19877== Searching for pointers to 1 not-freed blocks
==19877== Checked 86,656 bytes
==19877== 
==19877== 128 bytes in 1 blocks are definitely lost in loss record 1 of 1
==19877==    at 0x4C29BC3: malloc (vg_replace_malloc.c:299)
==19877==    by 0x401737: ??? (in /usr/bin/hostname)
==19877==    by 0x401ADE: ??? (in /usr/bin/hostname)
==19877==    by 0x401473: ??? (in /usr/bin/hostname)
==19877==    by 0x50723D4: (below main) (in /usr/lib64/libc-2.17.so)
==19877== 
==19877== LEAK SUMMARY:
==19877==    definitely lost: 128 bytes in 1 blocks
==19877==    indirectly lost: 0 bytes in 0 blocks
==19877==      possibly lost: 0 bytes in 0 blocks
==19877==    still reachable: 0 bytes in 0 blocks
==19877==         suppressed: 0 bytes in 0 blocks
==19877== 
==19877== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
==19877== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

Answer 1

安装调试信息后，我得到:

==31026== 128 bytes in 1 blocks are definitely lost in loss record 1 of 1
==31026==    at 0x483880B: malloc (vg_replace_malloc.c:309)
==31026==    by 0x10A827: localhost (hostname.c:129)
==31026==    by 0x10ABE6: show_name (hostname.c:264)
==31026==    by 0x10A556: main (hostname.c:547)

查看hostname命令的来源，在程序存在之前，localhost函数最多被调用3次。所以这个内存泄漏是完全有限的。程序员可能认为释放该内存并不重要，因为内核无论如何都会在进程终止时释放该进程的所有内存。在这种情况下，手动释放只会导致程序运行时间更长一些，而不会节省任何内存资源。

对于较大的程序，这种微优化可能仍然存在问题，因为如果许多分配受到影响，它会使调试真正的内存泄漏变得更加困难。但是 hostname 非常小，所以这里不是一个问题。