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

List:       kde-bugs-dist
Subject:    [valgrind] [Bug 79362] Debug info is lost for .so files when they are dlclose'd
From:       Philippe Waroquiers <bugzilla_noreply () kde ! org>
Date:       2017-07-31 21:34:19
Message-ID: bug-79362-17878-6rqkhA0xbA () http ! bugs ! kde ! org/
[Download RAW message or body]

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

Philippe Waroquiers <philippe.waroquiers@skynet.be> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |philippe.waroquiers@skynet.
                   |                            |be

--- Comment #63 from Philippe Waroquiers <philippe.waroquiers@skynet.be> ---
I quickly read the patch, here are a few comments

* For what concerns the gdbserver code and the xtree code: for sure, 
  using the current epoch will be as good (or as bad) as the current
  behaviour. But once the patch is committed, I will update the code
  to use a real epoch where it is better (basically, I think xtree should store
  an epoch, while gdbserver should normally be good enough with current epoch)
  But see below the idea to store epoch inside execontext,which should probably
  solve the xtree case.

* there are some tl_assert occurences in coregrind, where vg_assert should
  be used instead.

* for the --help of  --keep-debuginfo=..  this is not limited to memory leak
  stack traces as I understand, but all stack traces recorded as an execontext.
  E.g. IIUC, this is also valid for other types of errors.
  Same for the user manual.

* For execontext, instead of just storing the execcontext
  (e.g. in an mc chunk allocated by memecheck for each block), we now store
  an execontext + epoch.

  An alternative approach that will reduce the memory would be to store
  the epoch of an execontext in the execcontext itself.
  (by default, invalid epoch, indicating 'execontext valid in the current
  set of di').
  Then when a DI is archived, scan the execontext, and check if an execontext
  contains some addressed that are in the debuginfo being archived.
  If yes, change the execontext epoch from invalid to the current epoch
  (before unloading the DI).
  This should reduce the impact on all execontext users, both in terms
  of code change, and in terms of memory increase where an execontext
  has to be stored.
  This approach spares memory (and I think less impact on tools), but
  each unload of a DI means scanning the execontext.
  With this approach, when searching for an execontext that corresponds to
  a (fresh) stacktrace, only execontext that have an invalid epoch should
  be returned (as a fresh stack trace cannot match an execontext that
  has been marked with a real epoch). This should also avoid the
  problem of having 2 errors being the same, while in reality their 
  execontext are different, as a new error will never give back an 
  'old execontext' with a non invalid epoch.
  Similarly, IIUC, origin tracking will store an ec, not an ec + epoch.
  Storing the epoch inside the execcontext will also provide correct
  DI epoch for track origin.

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