[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:       Howard Chu <bugzilla_noreply () kde ! org>
Date:       2017-07-25 11:57:05
Message-ID: bug-79362-17878-K6wcSNei08 () http ! bugs ! kde ! org/
[Download RAW message or body]

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

--- Comment #61 from Howard Chu <hyc@symas.com> ---
Julian Seward wrote:
> 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?

It's been so long I don't remember the fine details any more. But I think it's 
safe to say, most of the time, if a shared object has been unloaded and a 
different one has been loaded, even if mapped to the same base address as the 
previous object, it is unlikely to have the same sizes and ordering of 
functions as the previous object, and thus unlikely to produce duplicates of 
any existing stack traces.

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