[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:       Julian Seward <bugzilla_noreply () kde ! org>
Date:       2017-07-25 11:19:17
Message-ID: bug-79362-17878-2jOUfxRf8q () http ! bugs ! kde ! org/
[Download RAW message or body]

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

--- Comment #59 from Julian Seward <jseward@acm.org> ---
(In reply to Howard Chu from comment #57)

> a clean fix has been available for nearly 5 years.

I'm trying to understand the proposed fix.  What I've gathered is:

(1) Each ExeContext has a 32-bit unique ID.

(2) m_execontext.c issues unique IDs in a monotonically increasing sequence,
    from ec_next_ecu.

(3) The patch extends struct DebugInfo so as to record the unique ID (2) at
    both the time the DebugInfo came into being and the point at which the
    associated .so was unmapped.

(4) DebugInfos for objects that have been unmapped are moved into their own
    linked list (unloadedDebugInfo_list)

(5) When symbolicating an ExeContext, I assume that you use its unique to
    identify which set of DebugInfos in unloadedDebugInfo_list can
    participate in its symbolisation (viz, should be used to look up symbol
    names etc).

This seems somewhat plausible.  But what I don't understand is how this
interacts with the fact that m_execontext doesn't necessarily issue a new
ExeContext with a new unique every time a stack unwind is requested.
Instead, it unwinds the stack, then checks to find if it already has an
ExeContext with that stack.  If so it merely gives out a pointer to the
existing version rather than creating a new one.

I'm not saying the patch is wrong.  I am saying I don't understand it.  Was
the m_execontext duplicate-stack-removal behaviour taken into account in the
design of the fix?

AFAICS, the only thing that you can conclude from the fact that

  execontext1.ecu > execontext2.ecu

is that execontext1's stack was observed for the first time before
execontext2's stack was observed for the first time.  And that the
two stacks are different, since the .ecus would be the same if the
stacks were the same.

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