[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [valgrind] [Bug 278972] Memcheck prints the wrong source file for certain functions.
From:       Philippe Waroquiers <philippe.waroquiers () skynet ! be>
Date:       2014-06-07 0:11:34
Message-ID: bug-278972-17878-23eKwWAY9Q () http ! bugs ! kde ! org/
[Download RAW message or body]

https://bugs.kde.org/show_bug.cgi?id=278972

--- Comment #11 from Philippe Waroquiers <philippe.waroquiers@skynet.be> ---
Created attachment 87054
  --> https://bugs.kde.org/attachment.cgi?id=87054&action=edit
patch to have valgrind understanding inlined function calls

This patch implements the support needed for stacktraces
showing inlined function calls.
The patch is (I think) in a reasonable state (ie. ready for review).
There are still some further actions to do (see below), but I intend to do
these once this patch is committed, as the patch is already big.

Reading the inlined dwarf call info is activated using the new clo
  --read-inline-info=yes
Default is no (even if an objective of this patch is to have a reasonable
cpu and memory overhead (see below discussion about performances).

Basically, the patch provides the following pieces:
1. Implement a new dwarf3 reader that reads the inlined call info
2. Some performance improvements done for this new parser, and
   on some common code between the new parser and the var info parser.
3. Use the parsed inlined info to produce stacktrace showing inlined calls
4. Use the parsed inlined info in the suppression matching and suppression
generation
5. and of course, some reg tests

1. new dwarf3 reader:
---------------------
Two options were possible: introduce reading the inlined info
in the current var info dwarf reader, or add a 2nd reader.
The 2nd approach was preferred, for the following reasons:
The var info reader is slow, memory hungry and quite complex.
Having a separate parsing phase for the inlined information
is simpler/faster when just reading the inlined info.
Possibly, a single parser would be faster when using both
--read-var-info=yes and --read-inline-info=yes.
However, var-info being extremely memory/cpu hungry, it is unlikely
to be used often, and having a separate parsing for inlined info
does in any case make not much difference.
(--read-var-info=yes is also now less interesting thanks to commit
r13991, which provides a fast and low memory "reasonable" location
for an address).

The inlined info parser reads the dwarf info to make calls
to priv_storage.h ML_(addInlInfo).

2. performance optimisations
----------------------------
* the abbrev cache has been improved:
  replace the 32 entries last used abbv code by a bigger
  cache, initialised initially by a single scan of the abbv section.
  On a big executable, reading the dwarf inline info was improved
  by a factor 2 (from 60 seconds to 30 seconds).
  The scanning of the dwarf var info was improved by the same 30 seconds
  (from 335 seconds to 300 seconds).
 Note: basically today, the abbrev parsing is a somewhat amortized quadratic
 algorithm: in average, parsing an abbreviation implies to parse first all
 preceeding abbreviation. The small 32 entries cache somewhat reduces
 the quadratic aspect, but not fully.
* The new parser skips the non interesting DIEs
  (the var-info parser has no logic to skip uninteresting DIEs).
* Some other minor perf optimisation here and there.
In total now, on a big executable, 20 seconds CPU are needed to
create the inlined info (on my slow x86 pentium).

Note: I intend to do some further performance optimisations
in the area of the abbreviation table: now, the abbreviation is re-read
for each parsing of a DIE. This is still a significant cost (due to get_ULEB128
being quite slow and called extremely frequently). The idea will be to put
'ready to be used' parsed abbrev in the cache, rather than just the position at
which the abbrev data can be (re-)read.

With regards to memory, the dinfo arena:
with inlined info: 184864768/134615040  max/curr mmap'd
without          : 158941184/109764608  max/curr mmap'd
So, basically, inlined information costs about 25Mb of memory for
my big executable.
I have some ideas to somewhat reduce this memory (and also reduce
the memory of some other information in dinfo, but to be done in a
follow-up patch).

3. produce better stack traces
------------------------------
VG_(describe_IP) has a new argument InlIPCursor *iipc which allows
to describe inlined function calls by doing repetitive calls 
to describe_IP. See pub_tool_debuginfo.h for a description.

4. suppression generation and matching
--------------------------------------
* suppression generation now also uses an InlIPCursor *iipc
  to generate a line for each inlined fn call.

* suppression matching: to allow suppression matching to
match one IP to several function calls in a suppression entry,
the 'inputCompleter' object (that allows to lazily generate
function or object names for a stacktrace when matching 
an error with a suppression) has been generalised a little bit
more to also lazily generate the input sequence.
VG_(generic_match) has been updated so as to be more generic
with respect to the input completer : when providing an
input completer, VG_(generic_match) does not need anymore
to produce/compute any input itself : this is all delegated
to the input completer.

5. various regtests
-------------------
to test stack traces with inlined calls, and suppressions
of (some of) these errors using inlined fn calls matching.


Work still to do:
-----------------
* some more work on improving the parsing performance
* improving the memory:
   currently, storage.c  ML_(addStr) comment lies by
   telling it avoids duplicating recently added string :
   there is no such logic. I had an experiment with this
   in a corner, and that can save some memory in the
   dinfo.
* directory name for the inlined function calls is not yet done: 
 This implies some code refactorisation and I would also like
 to reduce memory in this area. To be done in a follow up patch.
  Currently, there will be no directory information for inlined
  function calls.

-- 
You are receiving this mail because:
You are watching all bug changes.
[prev in list] [next in list] [prev in thread] [next in thread]