valgrind показывает утечку памяти в выводе команды hostname

Я просто играл с valgrind и случайно решил проверить вывод valgrind для некоторых команд linux.

Пытался ls -lrth и это работало нормально. По крайней мере, нет байтов в definitely lost,

тем не мение hostname вывод команды показывает то, чего я не ожидал, то есть утечка памяти.

Ошибка команды 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 ([email protected]) (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)