https://bugs.kde.org/show_bug.cgi?id=79362
--- Comment #59 from Julian Seward <jsew...@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.
