https://bugs.kde.org/show_bug.cgi?id=466172
Bug ID: 466172
Summary: SIGTRAP crash whenever getaddrinfo call is issued by
valgrind
Classification: Developer tools
Product: valgrind
Version: 3.20.0
Platform: RedHat Enterprise Linux
OS: Linux
Status: REPORTED
Severity: crash
Priority: NOR
Component: memcheck
Assignee: jsew...@acm.org
Reporter: do.not.spam.me.kde.bugzi...@gmail.com
Target Milestone: ---
SUMMARY
On my work RHEL 7.9 development system, valgrind coredumps and exits following
a SIGTRAP generated when calling the C library getaddrinfo function. This
occurs when running valgrind on our internal applications that call
getaddrinfo(), and also when running valgrind on the 'hostname -d' command.
This will produce a core file for the program. Output from valgrind is
available below, as is gdb output from the core file. The problem occurs with
the memcheck tool, and also the callgrind tool.
Further details given below are from running valgrind with hostname -d.
No failure occurs when running valgrind when hostname has no args, as it
does not generate a getaddrinfo call.
Similar results were seen when running the native valgrind v3.15 install for
RHEL 7.9, as seen when running a locally compiled valgrind v3.20 release. The
stack trace in the core file does not make a lot of sense as the system doesn't
currently have debuginfo packages installed. I'm trying to arrange these for
the glibc and hostname packages via a sysadmin, but this is not available at
the moment.
On my home host with VirtualBox, using RHEL 7.9, RHEL 8.7 and Fedora 35,
running valgrind with signal tracing turned on against 'hostname -d' shows two
SIGSEGV signals are raised but handled by valgrind and it continues to
successful command completion. I can't comment as to whether this should or
shouldn't happen, I've just used this to establish an expected baseline. When
run with strace instead of valgrind, no signals are found to be raised. When
running strace with valgrind and hostname -d, both strace and valgrind report
the two SIGSEGV signals.
STEPS TO REPRODUCE
1. valgrind --trace-signals=yes -v hostname -d
2.
3.
OBSERVED RESULT
valgrind handles a single SIGSEGV and continues, then handles a SIGTRAP and
core dumps. valgrind output indicates the crash happened during a getaddrinfo
call.
EXPECTED RESULT
Program being run with valgrind should survive a call to getaddrinfo and
continue running, so that memory leak checking can be carried out.
SOFTWARE/OS VERSIONS
Linux: RHEL 7.9 server without GUI installed
ADDITIONAL INFORMATION
Valgrind generates the following output
==80114== Memcheck, a memory error detector
==80114== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==80114== Using Valgrind-3.20.0-5147d671e4-20221024 and LibVEX; rerun with -h
for copyright info
==80114== Command: hostname -d
==80114== Parent PID: 20454
==80114==
--80114--
--80114-- Valgrind options:
--80114-- --trace-signals=yes
--80114-- -v
--80114-- --log-file=valgrind.out
--80114-- Contents of /proc/version:
--80114-- Linux version 3.10.0-1160.81.1.el7.x86_64
(mockbu...@x86-vm-38.build.eng.bos.redhat.com) (gcc version 4.8.5 20150623 (Red
Hat 4.8.5-44) (GCC) ) #1 SMP Thu Nov 24 12:21:22 UTC 2022
--80114--
--80114-- Arch and hwcaps: AMD64, LittleEndian,
amd64-cx16-lzcnt-rdtscp-sse3-ssse3-avx-avx2-bmi-f16c-rdrand
--80114-- Page sizes: currently 4096, max supported 4096
--80114-- Valgrind library directory: /home/auser/local/libexec/valgrind
--80114-- Reading syms from /usr/bin/hostname
--80114-- object doesn't have a symbol table
--80114-- Reading syms from /usr/lib64/ld-2.17.so
--80114-- Reading syms from
/home/auser/local/libexec/valgrind/memcheck-amd64-linux
--80114-- object doesn't have a dynamic symbol table
--80114-- Scheduler: using generic scheduler lock implementation.
--80114-- Max kernel-supported signal is 64, VG_SIGVGKILL is 64
--80114-- Reading suppressions file:
/home/auser/local/libexec/valgrind/default.supp
==80114== embedded gdbserver: reading from
/tmp/vgdb-pipe-from-vgdb-to-80114-by-auser-on-hostname.localdomain
==80114== embedded gdbserver: writing to
/tmp/vgdb-pipe-to-vgdb-from-80114-by-auser-on-hostname.localdomain
==80114== embedded gdbserver: shared mem
/tmp/vgdb-pipe-shared-mem-vgdb-80114-by-auser-on-hostname.localdomain
==80114==
==80114== TO CONTROL THIS PROCESS USING vgdb (which you probably
==80114== don't want to do, unless you know exactly what you're doing,
==80114== or are doing some strange experiment):
==80114== /home/auser/local/libexec/valgrind/../../bin/vgdb --pid=80114
...command...
==80114==
==80114== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==80114== /path/to/gdb hostname
==80114== and then give GDB the following command
==80114== target remote | /home/auser/local/libexec/valgrind/../../bin/vgdb
--pid=80114
==80114== --pid is optional if only one valgrind process is running
==80114==
--80114-- REDIR: 0x4019e40 (ld-linux-x86-64.so.2:strlen) redirected to
0x580cc9e5 (vgPlain_amd64_linux_REDIR_FOR_strlen)
--80114-- REDIR: 0x4019c10 (ld-linux-x86-64.so.2:index) redirected to
0x580cc9ff (vgPlain_amd64_linux_REDIR_FOR_index)
--80114-- sync signal handler: signal=11, si_code=1, EIP=0x4001cf1,
eip=0x1003803576, from kernel
--80114-- SIGSEGV: si_code=1 faultaddr=0x1ffeffd9b8 tid=1 ESP=0x1ffeffd9b8
seg=0x1ffe001000-0x1ffeffdfff
--80114-- -> extended stack base to 0x1ffeffd000
--80114-- Reading syms from
/home/auser/local/libexec/valgrind/vgpreload_core-amd64-linux.so
--80114-- Reading syms from
/home/auser/local/libexec/valgrind/vgpreload_memcheck-amd64-linux.so
==80114== WARNING: new redirection conflicts with existing -- ignoring it
--80114-- old: 0x04019e40 (strlen ) R-> (0000.0) 0x580cc9e5
vgPlain_amd64_linux_REDIR_FOR_strlen
--80114-- new: 0x04019e40 (strlen ) R-> (2007.0) 0x04c30b10
strlen
--80114-- REDIR: 0x4019dc0 (ld-linux-x86-64.so.2:strcmp) redirected to
0x4c31d00 (strcmp)
--80114-- REDIR: 0x4019fa0 (ld-linux-x86-64.so.2:strncmp) redirected to
0x4c31420 (strncmp)
--80114-- REDIR: 0x401aa80 (ld-linux-x86-64.so.2:mempcpy) redirected to
0x4c35d90 (mempcpy)
--80114-- REDIR: 0x401abd0 (ld-linux-x86-64.so.2:stpcpy) redirected to
0x4c349d0 (stpcpy)
--80114-- Reading syms from /usr/lib64/liboneagentproc.so
--80114-- object doesn't have a symbol table
--80114-- Reading syms from /usr/lib64/libnsl-2.17.so
--80114-- Reading syms from /usr/lib64/libc-2.17.so
==80114== WARNING: new redirection conflicts with existing -- ignoring it
--80114-- old: 0x052e8000 (memalign ) R-> (1011.0) 0x04c2fde2
memalign
--80114-- new: 0x052e8000 (memalign ) R-> (1017.0) 0x04c2fdb2
aligned_alloc
==80114== WARNING: new redirection conflicts with existing -- ignoring it
--80114-- old: 0x052e8000 (memalign ) R-> (1011.0) 0x04c2fde2
memalign
--80114-- new: 0x052e8000 (memalign ) R-> (1017.0) 0x04c2fd85
aligned_alloc
==80114== WARNING: new redirection conflicts with existing -- ignoring it
--80114-- old: 0x052e8000 (memalign ) R-> (1011.0) 0x04c2fde2
memalign
--80114-- new: 0x052e8000 (memalign ) R-> (1017.0) 0x04c2fdb2
aligned_alloc
==80114== WARNING: new redirection conflicts with existing -- ignoring it
--80114-- old: 0x052e8000 (memalign ) R-> (1011.0) 0x04c2fde2
memalign
--80114-- new: 0x052e8000 (memalign ) R-> (1017.0) 0x04c2fd85
aligned_alloc
--80114-- REDIR: 0x52f21d0 (libc.so.6:strcasecmp) redirected to 0x4a247af
(_vgnU_ifunc_wrapper)
--80114-- REDIR: 0x52eef40 (libc.so.6:strnlen) redirected to 0x4a247af
(_vgnU_ifunc_wrapper)
--80114-- REDIR: 0x52f44d0 (libc.so.6:strncasecmp) redirected to 0x4a247af
(_vgnU_ifunc_wrapper)
--80114-- REDIR: 0x52f19a0 (libc.so.6:memset) redirected to 0x4a247af
(_vgnU_ifunc_wrapper)
--80114-- REDIR: 0x52f1950 (libc.so.6:memcpy@GLIBC_2.2.5) redirected to
0x4a247af (_vgnU_ifunc_wrapper)
--80114-- REDIR: 0x52f08b0 (libc.so.6:strncpy) redirected to 0x4a247af
(_vgnU_ifunc_wrapper)
--80114-- REDIR: 0x52ef020 (libc.so.6:strncmp) redirected to 0x4a247af
(_vgnU_ifunc_wrapper)
--80114-- REDIR: 0x52ee850 (libc.so.6:strcpy) redirected to 0x4a247af
(_vgnU_ifunc_wrapper)
--80114-- REDIR: 0x52f2020 (libc.so.6:stpcpy) redirected to 0x4a247af
(_vgnU_ifunc_wrapper)
--80114-- REDIR: 0x52eee10 (libc.so.6:strlen) redirected to 0x4a247af
(_vgnU_ifunc_wrapper)
--80114-- REDIR: 0x52ed300 (libc.so.6:index) redirected to 0x4a247af
(_vgnU_ifunc_wrapper)
--80114-- REDIR: 0x52f1380 (libc.so.6:bcmp) redirected to 0x4a247af
(_vgnU_ifunc_wrapper)
--80114-- REDIR: 0x52f8270 (libc.so.6:rawmemchr) redirected to 0x4a247af
(_vgnU_ifunc_wrapper)
--80114-- REDIR: 0x52ed3c0 (libc.so.6:strcmp) redirected to 0x4a247af
(_vgnU_ifunc_wrapper)
--80114-- REDIR: 0x52f6bc0 (libc.so.6:memcpy@@GLIBC_2.14) redirected to
0x4a247af (_vgnU_ifunc_wrapper)
--80114-- REDIR: 0x52f1b00 (libc.so.6:mempcpy) redirected to 0x4a247af
(_vgnU_ifunc_wrapper)
--80114-- REDIR: 0x5307fd0 (libc.so.6:strstr) redirected to 0x4a247af
(_vgnU_ifunc_wrapper)
--80114-- REDIR: 0x52f0930 (libc.so.6:__GI_strrchr) redirected to 0x4c304d0
(__GI_strrchr)
--80114-- REDIR: 0x52f6c30 (libc.so.6:__GI_memcpy) redirected to 0x4c329b0
(__GI_memcpy)
--80114-- REDIR: 0x52eee60 (libc.so.6:__GI_strlen) redirected to 0x4c30a70
(__GI_strlen)
--80114-- REDIR: 0x52f08f0 (libc.so.6:rindex) redirected to 0x4a247af
(_vgnU_ifunc_wrapper)
--80114-- REDIR: 0x53a2d50 (libc.so.6:__strrchr_sse42) redirected to 0x4c30560
(__strrchr_sse42)
--80114-- REDIR: 0x53a0fc0 (libc.so.6:__strcmp_sse42) redirected to 0x4c31cb0
(__strcmp_sse42)
--80114-- REDIR: 0x52ed340 (libc.so.6:__GI_strchr) redirected to 0x4c30600
(__GI_strchr)
--80114-- REDIR: 0x52e7740 (libc.so.6:malloc) redirected to 0x4c2b100 (malloc)
--80114-- REDIR: 0x52f1030 (libc.so.6:memchr) redirected to 0x4c31da0 (memchr)
--80114-- delivering signal 5 (SIGTRAP):1 to thread 1
--80114-- delivering 5 (code 1) to default handler; action: terminate+core
==80114==
==80114== Process terminating with default action of signal 5 (SIGTRAP):
dumping core
--80114-- -> extended stack base to 0x1ffefff000
==80114== at 0x53495E1: getaddrinfo (in /usr/lib64/libc-2.17.so)
==80114== by 0x1FFEFFFA7F: ???
==80114== by 0x529B225: getenv (in /usr/lib64/libc-2.17.so)
==80114==
==80114== HEAP SUMMARY:
==80114== in use at exit: 128 bytes in 1 blocks
==80114== total heap usage: 1 allocs, 0 frees, 128 bytes allocated
==80114==
==80114== Searching for pointers to 1 not-freed blocks
==80114== Checked 2,422,200 bytes
==80114==
==80114== LEAK SUMMARY:
==80114== definitely lost: 128 bytes in 1 blocks
==80114== indirectly lost: 0 bytes in 0 blocks
==80114== possibly lost: 0 bytes in 0 blocks
==80114== still reachable: 0 bytes in 0 blocks
==80114== suppressed: 0 bytes in 0 blocks
==80114== Rerun with --leak-check=full to see details of leaked memory
==80114==
==80114== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Trace/breakpoint trap (core dumped)
@@@@@@@@@@@@@@@@@@@@@@
GDB Output from subsequent run
gdb `which valgrind` vgcore.78953
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-120.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/auser/local/bin/valgrind...done.
warning: core file may not match specified executable file.
[New LWP 78953]
Core was generated by `'.
Program terminated with signal 5, Trace/breakpoint trap.
#0 0x00000000053495e1 in ?? ()
(gdb) where
#0 0x00000000053495e1 in ?? ()
#1 0x0000000000401b19 in myvprintf_str (send=0x1ffefff970, send_arg2=0x1,
flags=<optimized out>, width=<optimized out>,
str=<optimized out>, capitalise=1 '\001') at m_debuglog.c:786
#2 0x0000000000000000 in ?? ()
(gdb)
The line "#0 0x00000000053495e1 in ?? ()" from gdb output matches the valgrind
output
==80114== at 0x53495E1: getaddrinfo (in /usr/lib64/libc-2.17.so)
--
You are receiving this mail because:
You are watching all bug changes.
