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.
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.
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.
The new binutils ld -z separate-code option creates multiple read-only
PT_LOAD segments and might place .rodata in a non-executable segment.
Allow and keep track of separate read-only segments and allow a readonly
page with .rodata section.
Based on patches from Tom Hughes <tom@compton.nu> and
H.J. Lu <hjl.tools@gmail.com>.
https://bugs.kde.org/show_bug.cgi?id=395682
Adding MIPS N32 ABI support.
BZ issue - #345763.
Contributed and maintained by mulitple people over the years:
Crestez Dan Leonard, Maran Pakkirisamy, Dimitrije Nikolic,
Aleksandar Rikalo, Tamara Vlahovic.
Follow up to "Introduce RegWord type" change.
Part of the changes required for BZ issue - #345763.
Contributed by:
Tamara Vlahovic and Dimitrije Nikolic.
Bug #393062 - Reading build-id ELF note through phdrs triggers
"debuginfo reader: ensure_valid failed"
Skip the phdrs when we have to search the shdrs. In separate
.debug files the phdrs might not be valid (they are a copy of
the main ELF file) and might trigger assertions when getting
image notes based on them.
Normally, an inlined call has a dwarf entry that points at the abstract origin, i.e. the
function that was inlined.
However, in some cases, the abstract origin tag is not present (observed with gcc 6.3.0, when
compiling with link time optimisation).
Such missing abstract origin was then causing an error message when reading the dwarf debug info.
This patch ensures we handle this case more gracefully, by using UnknownInlinedFun as inlined
function name for such a missing abstract origin;
As reported by Matthias Schwarzott <zzam@gentoo.org>. Testcase patch from him. The fix is
for check_CFSI_related_invariants() to avoid checking for overlaps against DebugInfos that are
in 'archived' status, since -- if a previously dlopened-and-then-dlclosed object is later
re-dlopened -- this may cause an overlap between the active and archived DebugInfos, which
is of no consequence. If the kernel maps the object to the same VMA the second time around
then there will *certainly* be an overlap.
https://bugs.kde.org/show_bug.cgi?id=387773
The path to the alt file is relative to the actual debug file.
Make sure that we got the real file, not a (build-id) symlink.
Also handle the case where a debug or alt file is an absolute path.
This patch implements the flag --delta-stacktrace=yes/no.
Yes indicates to calculate the full history stack traces by
changing just the last frame if no call/return instruction was
executed.
This can speed up helgrind by up to 25%.
This flags is currently set to yes only on linux x86 and amd64, as some
platform dependent validation of the used heuristics is needed before
setting the default to yes on a platform. See function check_cached_rcec_ok
in libhb_core.c for more details about how to validate/check the behaviour
on a new platform.
Under specific circumstances, setting 2048 as a size of symbol of unknown
size causes that symbol crosses unmapped region. This further causes an
assertion in Valgrind.
Compute possible size by computing maximal size the symbol can have within
its section.
Patch by Tamara Vlahovic.
We can have stacktraces such as:
==41840== by 0x10000927: a1 (deep.c:27)
==41840== by 0x1000096F: main (deep.c:35)
==41840== by 0x4126BEB: generic_start_main.isra.0 (in /usr/lib64/libc-2.17.so)
==41840== by 0x4126E13: __libc_start_main (in /usr/lib64/libc-2.17.so)
So, add generic_start_main.isra.0 as a below main function.
This fixes the test massif/tests/deep-D
The code handling array bounds is not ready to accept a reference
to something else (not very clear what this reference could be) :
the code only expects directly the value of a bound.
So, it was using the reference (i.e. an offset somewehere in the debug
info) as the value of the bound.
This then gave huge bounds for some arrays, causing an overlap
in the stack variable handling code in exp-sgcheck.
Such references seems to be used sometimes for arrays with variable
size stack allocated.
Fix (or rather bypass) the problem by not considering that we have
a usable array bound when a reference is given.
* produce (more) user messages when valgrind cannot read a pdb file.
* recover properly from an invalid/unsupported pdb file.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16465
This makes reading of compressed debuginfo usable for very large object files.
It also adds a bunch extra documentation about a tricky invariant in the
compressed debuginfo handling (a recursive cache refill path!) and adds a
whole bunch of assertions.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16279
* sym name cache to cache the 'isText' characteristic of the cached sym_name
* implement the match anywhere also in the cache
Not handling matchAnywhere has bad performance effect on callgrind, as almost many
IPs were considered as a fn entry, while they were not.
* use the same convention to name the findText argument
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16136
Support work for xtree: as xtree implementation makes a high
nr of calls to get_sym_name, this cache improves the performance
as usually, stacktraces are repeatitively querying the same
addresses.
The cache follows the same principle as the cfsi_m_cache.
In particular, cache is cleared together with the cfsi_m cache.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16121
SUNWDTRACE program header. Newer Solaris no longer utilizes
this program header as a scratchspace for DTrace fasttrap
provider, before libc is loaded.
For the time being, it serves as a space for initial thread
pointer.
n-i-bz
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15936
for Elf{32,64}_Chdr. This is fallout from r15868. That commit provided
a configure test, but the resulting config.h was not included here, causing
the test results to be ignored.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15869
- zlib ELF gABI format with SHF_COMPRESSED flag (gcc option -gz=zlib)
- zlib GNU format with .zdebug sections (gcc option -gz=zlib-gnu)
Patch by: Aleksandar Rikalo <aleksandar.rikalo@imgtec.com>
Fixes BZ#303877
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15868
is no longer needed. The situation with multiple ".rodata" sections existed
only between dozens of builds of Solaris 12.
Fixes BZ#360749
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15853
* Complain instead of asserting when negative line nr in inline info
* use a macro to factorise the complain once logic about lineno limits
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15780
At many places, we have:
VG_(fun(a,b,c))
instead of
VG_(fun)(a,b,c)
So, fix these cases, found using:
grep -n -i -e 'VG_([a-z][a-z0-9_]*[^a-z0-9_)]' *.c */*.c */*/*.c
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15776
Line numbers should correctly reflect all instructions belonging to a source line,
regardless of is_stmt value. Previously only instructions covered by
'is_stmt = 1' were attributed to a source line.
Fixes BZ#356044
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15741
This implements the interception of all globally public allocation
functions by default. It works by adding a flag to the spec to say the
interception only applies to global functions. Which is set for the
somalloc spec. The librarypath to match is set to "*" unless the user
overrides it. Then each DiSym keeps track of whether the symbol is local
or global. For a spec which has isGlobal set only isGlobal symbols will
match.
Note that because of padding to keep the addresses in DiSym aligned the
addition of the extra bool isGlobal doesn't actually grow the struct.
The comments explain how the struct could be made more compact on 32bit
systems, but this isn't as easy on 64bit systems. So I didn't try to do
that in this patch.
For ELF symbols keeping track of which are global is trivial. For pdb I
had to guess and made only the "Public" symbols global. I don't know
how/if macho keeps track of global symbols or not. For now I just mark
all of them local (which just means things work as previously on platforms
that use machos, no non-system symbols are matches by default for somalloc
unless the user explicitly tells which library name to match).
Included are two testcases for shared libraries (wrapmalloc) and staticly
linked (wrapmallocstatic) malloc/free overrides that depend on the new
default. One existing testcase (new_override) was adjusted to explicitly
not use the new somalloc default because it depends on a user defined
new implementation that has side-effects and should explicitly not be
intercepted.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15726
The ELF debug info reader on Solaris now performs a quick pre-scan of section
headers for .rodata sections. If there are multiple .rodata sections
present then symbols from .symtab are scanned which section they point to.
The "true" .rodata section is thus determined.
Fixes BZ#353802.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15719
hardwired absolute path names. People can always arrange $PATH
such that these tools are found.
Fixes BZ #294065. Patch by Austin English <austinenglish@gmail.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15652
