Valgrind 在主机名命令输出中显示内存泄漏

valgrind shows memory leak in hostname command output

本文关键字:显示 内存 泄漏 输出 命令 主机 Valgrind      更新时间:2023-10-16

我只是在玩 valgrind,并随机决定检查 valgrind 输出以获取一些 linux 命令。

尝试了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)

安装调试信息后,我得到这个:

==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 函数三次。 所以这个内存泄漏是完全有界的。 程序员可能认为释放此内存无关紧要,因为内核无论如何都会在进程终止时释放进程的所有内存。 在这种情况下,手动释放只会导致程序运行时间稍长一点,而不会节省任何内存资源。

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