This option allows to list the detected errors and show the used
suppressions without increasing the verbosity.
Increasing the verbosity also activates a lot of messages that
are often not very useful for the user.
So, this option allows to see the list of errors and used suppressions
independently of the verbosity.
Note if a high verbosity is selected, the behaviour is unchanged.
In other words, when specifying -v, the list of detected errors
and the used suppressions are still shown, even if
--show-error-list=yes and -s are not used.
Each tool producing errors had identical code to produce this msg.
Factorize the production of the message in m_main.c
This prepares the work to have a specific option to show the list
of detected errors and the count of suppressed errors.
This has a (small) visible effect on the output of memcheck:
Instead of producing
For counts of detected and suppressed errors, rerun with: -v
Use --track-origins=yes to see where uninitialised values come from
memcheck now produces:
Use --track-origins=yes to see where uninitialised values come from
For counts of detected and suppressed errors, rerun with: -v
i.e. the track origin and counts of errors msg are inverted.
The sys_ptrace post didn't mark the thread as being in traceme mode.
This occassionally would make the memcheck/tests/linux/getregset.vgtest
testcase fail. With this patch it reliably passes.
In final_tidyup we setup the guest to call the freeres_wrapper, which
will (possibly) call __gnu_cxx::__freeres() and/or __libc_freeres().
In a couple of cases (ppc64be, ppc64le and mips32) this involves setting
up one or more helper registers. Since we setup these guest registers
we should make sure to mark them as fully defined. Otherwise we might
see spurious warnings about undefined value usage if the guest register
happened to not be fully defined before.
This fixes PR402006.
This patch addresses the following:
* Fix the implementation of LOCGHI. Previously Valgrind performed 32-bit
sign extension instead of 64-bit sign extension on the immediate value.
* Advertise VXRS in HWCAP. If no VXRS are advertised, but the program
uses vector registers, this could cause problems with a glibc built with
"-march=z13".
The primary and secondary coregrind libraries must be updated
when m_main.c or m_libcsetjmp.c are changed.
A dependency was missing between libcoregrind*.a and libnolto_coregrind*.a,
and so tools were not relinked when m_main.c or m_libcsetjmp.c were
changed.
Author: Nicholas Nethercote <nnethercote@mozilla.com>
Use inlined frames in Massif XTree output.
This makes Massif's output much easier to follow.
The commit also removes a -1 used on all Massif stack frame addresses.
There was a big comment questioning the presence of that -1, and with it
gone the addresses now match those produced by DHAT.
Without this, a signal handler compiled by Clang 6, which uses movdqa to load/store
relative to ESP, segfaults because the resulting address isn't 16-aligned.
At least with libopenblas, we can have several rx mappings
with some holes between mappings.
Change the invariant (2) checking so that such holes are ok,
as long as no cfsi refers to such an hole.
This implements various z/Architecture instructions that conditionally
yield a data exception ("trap"). The condition is either based on a
comparison being true ("compare and trap") or on a loaded value being
zero ("load and trap"). These instructions haven't been widely used in
the past, but may now be emitted by newer compilers. Note that the
resulting signal for a data exception is SIGFPE, not SIGTRAP. Thus this
patch also adds a new jump kind Ijk_SigFPE.
On signal handler return, restore r0 .. r15 inclusive from the sigcontext that we
gave to the handler, so that any changes the handler has made to those values
will take effect on return.
* coregrind/m_redir.c: whitespace changes only
* memcheck/mc_main.c:
- change 6 guards of the form "defined (VGABI_N32)" to
"defined(VGA_mips64) && defined(VGABI_N32)"
- Fix up poor indentation
When code uses utimensat with UTIME_NOW or UTIME_OMIT valgrind memcheck
would generate a warning. But as the utimensat manpage says:
If the tv_nsec field of one of the timespec structures has the special
value UTIME_NOW, then the corresponding file timestamp is set to the
current time. If the tv_nsec field of one of the timespec structures
has the special value UTIME_OMIT, then the corresponding file timestamp
is left unchanged. In both of these cases, the value of the corre‐
sponding tv_sec field is ignored.
So ignore the timespec tv_sec when tv_nsec is set to UTIME_NOW or
UTIME_OMIT.
Some applications are mapping an object ro, and then unmaps it directly.
In such a case, we have a di that contains obsolete fsm.maps (not matching
OS mappings). The di for this unmapped object is not active,
and has no dinfo (have_dinfo == False).
(more generally, fsm.maps can contain a whole bunch of obsolete mappings).
Later on, some other libs can be mapped with a mapping overlapping
this obsolete mapping.
A di that never had its debug info loaded can really be discarded,
even if CG_(clo_keep_debuginfo).
In such a case, it is normal to have to discard a not active di.
(it might be better to keep fsm.maps in sync with the real OS
mapping, but that is a much bigger change/fix).
The FSM debug tracing was static, it is now dynamic according
to debug loglevel >= 3.
The below is an extract of the trace showing what happens.
SYSCALL[4384,1](257) sys_openat ( 4294967196, 0x4244398(/usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqeglfs.so), 524288 ) --> [async] ...
SYSCALL[4384,1](257) ... [async] --> Success(0x3)
SYSCALL[4384,1](72) sys_fcntl[ARG3=='arg'] ( 3, 2, 1 )[sync] --> Success(0x0)
SYSCALL[4384,1](5) sys_newfstat ( 3, 0x1ffefff8b0 )[sync] --> Success(0x0)
SYSCALL[4384,1](5) sys_newfstat ( 3, 0x1ffefff9c0 )[sync] --> Success(0x0)
SYSCALL[4384,1](9) sys_mmap ( 0x0, 10520, 1, 1, 3, 0 )--4384-- di_notify_mmap-0:
--4384-- di_notify_mmap-1: 0x4027000-0x4029fff r--
--4384-- di_notify_mmap-2: /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqeglfs.so
--4384-- di_notify_mmap-3: is_rx_map 0, is_rw_map 0, is_ro_map 1
--4384-- di_notify_mmap-4: noting details in DebugInfo* at 0x10024CEA10
--4384-- di_notify_mmap-6: no dinfo loaded /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqeglfs.so (no rx or no rw mapping)
--> [pre-success] Success(0x4027000)
SYSCALL[4384,1](3) sys_close ( 3 )[sync] --> Success(0x0)
SYSCALL[4384,1](11) sys_munmap ( 0x4027000, 10520 )[sync] --> Success(0x0)
^^^^ the above munmap has not cleaned up or removed anything in DebugInfo* at 0x10024CEA10
Later on, /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so is mapped
overlapping the memory where libqeglfs.so was mapped ro.
Now, this cleans up the (useless) di that never had have_dinfo true, e.g.
------ start ELF OBJECT -------------------------------------------------------
------ name = /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so
...
--4384-- Discarding syms at 0x0-0x0 in /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqeglfs.so (have_dinfo 0)
(the 0x0-0x0 in the trace is because there was never any text mapping for libqeglfs.so).
In check_CFSI_related_invariants, this commit improves the check for invariant
(2), which, as noted in an existing comment, "might need to be improved".
Instead of assuming that the CFSI range fits entirely into one "rx" mapping,
check that it is covered by the union of all the "rx" mappings we have. This
is the correct check. The previous check was observed to have failed as below
for at least some Clang generated objects (possibly in conjunction with lld as
the linker.)
valgrind: m_debuginfo/debuginfo.c:717 (check_CFSI_related_invariants): Assertion 'cfsi_fits' failed.
* discard_or_archive_marked_DebugInfos: clear the mark bit for a Debuginfo
that will be archived
* discard_DebugInfos_which_overlap_with: when selecting DebugInfos to be
discarded or archived, fix a mistake in which some mark bits wouldn't be
changed at all, meaning their "old" value was used to influence the current
operation.
These may (or may not) fix#393146; at the very least, they are somehow
related.
Support for the bpf system call was added in a previous commit, but
did not include tracking for file descriptors handled by the call.
Add checks and tracking for file descriptors. Check in PRE() wrapper
that all file descriptors (pointing to object such as eBPF programs or
maps, cgroups, or raw tracepoints) used by the system call are valid,
then add tracking in POST() wrapper for newly produced file descriptors.
As the file descriptors are not always processed in the same way by the
bpf call, add to the header file some additional definitions from bpf.h
that are necessary to sort out under what conditions descriptors should
be checked in the PRE() helper.
Fixes: 388786 - Support bpf syscall in amd64 Linux
Add support for bpf() Linux-specific system call on amd64 platform. The
bpf() syscall is used to handle eBPF objects (programs and maps), and
can be used for a number of operations. It takes three arguments:
- "cmd" is an integer encoding a subcommand to run. Available subcommand
include loading a new program, creating a map or updating its entries,
retrieving information about an eBPF object, and may others.
- "attr" is a pointer to an object of type union bpf_attr. This object
converts to a struct related to selected subcommand, and embeds the
various parameters used with this subcommand. Some of those parameters
are read by the kernel (example for an eBPF map lookup: the key of the
entry to lookup), others are written into (the value retrieved from
the map lookup).
- "attr_size" is the size of the object pointed by "attr".
Since the action performed by the kernel, and the way "attr" attributes
are processed depends on the subcommand in use, the PRE() and POST()
wrappers need to make the distinction as well. For each subcommand, mark
the attributes that are read or written.
For some map operations, the only way to infer the size of the memory
areas used for read or write operations seems to involve reading
from /proc/<pid>/fdinfo/<fd> in order to retrieve the size of keys
and values for this map.
The definitions of union bpf_attr and of other eBPF-related elements
required for adequately performing the checks were added to the Linux
header file.
Processing related to file descriptors is added in a follow-up patch.
The sys_prctl wrapper with PR_SET_NAME option reads an ASCII string passed
as its second argument. This string is supposed to be shorter than a given
limit. As the actual length of the string is unknown, the PRE() wrapper
performs a number of checks on it, including, in worst case, trying to
dereference it byte by byte.
To avoid re-implementing all this logic for other wrappers that could
need it, get the string processing out of the wrapper and move it to a
static function. Note that passing tid as an argument to the function is
required for macros PRE_MEM_RASCIIZ and PRE_MEM_READ to work properly.
Once we've read debuginfo for an object, ignore all further mappings. If we
don't do that, applications that mmap in their own objects to inspect them for
whatever reason, will cause "irrelevant" mappings to be recorded in the
object's fsm.maps table. This can lead to serious problems later on.
This has become necessary because 64aa729bfa of
Thu Jul 12 2018 (the fix for bug 395682) started recording readonly segments
in the fsm.maps table, where before they were ignored.
arch_prctl used to be amd64 only. But since linux 4.12 it is also
implemented for i386. And since glibc 2.28 ld.so will use it to see
if the cpu/kernel provides CET support.
To prevent seeing:
WARNING: unhandled x86-linux syscall: 384
You may be able to write your own handler.
Read the file README_MISSING_SYSCALL_OR_IOCTL.
Nevertheless we consider this a bug. Please report
it at http://valgrind.org/support/bug_reports.html.
on every program run under valgrind just make it explicitly
not implemented (ENOSYS). This is fine for the glibc usage.
It just indicates there is no CET support.
Probably not very critical, as very surely the process will die
shortly after, but better still clean the memory, as the code
was already doing some effort to free memory (e.g. VG_(free)(seg_starts);).
Note that when testing on debian 9/amd64, the resulting core dump
was not very usable (e.g. was not really showing what the guest threads
are doing). So, there must be a bug in the core dumping logic.
On amd64, on a big application, a vgdb call that wakes up the application
using ptrace fails unfrequently (we speak about one failure every few thousands vgdb calls).
The failure started to appear when valgrind was compiled with gcc 7.3 instead of gcc 6.4
After investigation:
* gcc 7.3 is using (more) sse instructions
* Such instructions imply to have a stack pointer aligned on 16 bytes.
* vgdb-invoker-ptrace.c 'ptrace' modification of the stack pointer was
not respecting the amd64 ABI convention to align on 16 bytes.
It was also not protecting the red zone (unclear if this could cause
the problem, but in any case, this ptrace logic is similar to a
signal handler, and cannot modify the redzone.
The fix consists in respecting the ABI.
Without the patch, segmentation violation due to an sse instruction
being executed with an address on the stack not aligned on 16 bytes,
happening something like every 5000 vgdb execution.
With the patch, 250_000 executions without problems.
The stack base starts at the beginning of the protection page/zone,
so we need to add VG_STACK_GUARD_SZB to get the real lowest usable
byte.
As the VgStack is an opaque type, add a function in aspacemgr to
return the Addr of the first lowest usable byte.
Currently arch_prctl calls VG_(core_panic) when it sees an unknown
arch_prctl option which kills the process. glibc uses arch_prctl with
an (as yet) unknown option to see if the kernel supports CET. This
breaks any application running under valgrind on x86_64 with:
valgrind: the 'impossible' happened:
Unsupported arch_prctl option
Thread 1: status = VgTs_Runnable (lwpid 19934)
==19934== at 0x121A15: get_cet_status (cpu-features.c:28)
==19934== by 0x121A15: init_cpu_features (cpu-features.c:474)
==19934== by 0x121A15: dl_platform_init (dl-machine.h:228)
==19934== by 0x121A15: _dl_sysdep_start (dl-sysdep.c:231)
==19934== by 0x10A1D7: _dl_start_final (rtld.c:413)
==19934== by 0x10A1D7: _dl_start (rtld.c:520)
We already handle all known options. It would be better to do as the
kernel does and just return failure with EINVAL instead.
