https://bugs.kde.org/show_bug.cgi?id=439897
--- Comment #6 from Matt Whitlock <k...@mattwhitlock.name> --- (In reply to Milian Wolff from comment #5) > can you please try the latest master and see if you are still seeing this > breakage? Yes, that fixed it. I no longer get nonsense traces in Heaptrack, and I actually managed to find and patch that leak in plasmashell! > Quite frankly, I'm super stumped by this breakage as I mentioned in the > commit message for the workaround I implemented now... I think it should be expected that the instruction pointer addresses that are on the stack should point at the instruction just after the call instruction, as that's how the hardware works. (The call instruction pushes the address of the *next* instruction before branching to the target of the call. That saves having to re-decode the call instruction upon later return from the subroutine to determine how large the call instruction's operand is and thus where the next instruction begins.) > I just wonder how it could ever have worked at this > stage. Considering how many people have used heaptrack in the past... Maybe Heaptrack's stack traces have been "good enough," or maybe libunwind used to adjust the IPs in the stack trace to point at the call instructions but stopped doing that at some point. Technically, I am not sure that subtracting a constant 1 from the addresses is quite valid, as then you'll end up pointing at part of the call instruction's operand rather than at the call instruction's opcode, but maybe that's good enough to determine an accurate source code location for the function call. -- You are receiving this mail because: You are watching all bug changes.
