我只是在玩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)
答案 0 :(得分：2)
安装调试信息后，我得到了：
==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次。因此，此内存泄漏已完全解决。程序员可能认为释放此内存无关紧要，因为无论如何终止，内核都会释放进程的所有内存。在这种情况下，手动重新分配只会使程序运行更长的时间，而不会节省任何内存资源。
对于较大的程序，这样的微优化可能仍然是有问题的，因为如果影响许多分配，它会使调试 real 内存泄漏变得更加困难。但是hostname很小，因此这里不必担心。