https://bugs.kde.org/show_bug.cgi?id=439897
--- Comment #2 from Matt Whitlock <k...@mattwhitlock.name> --- (In reply to Milian Wolff from comment #1) > Since you are using gentoo: Are the debug symbols you are using for > plasmashell and qt and so forth matching the build that you profiled? Yes. The debug symbols get installed (beneath /usr/lib/debug) at the same time as the binaries are installed to the live file system by the package manager. The debug symbols are produced in the same build process that produces the executable/library binaries and are then split apart from the binaries to be filed separately. Gentoo doesn't use separate packages for debug symbols like some distros do. > Is this easily reproducible for me somehow? I'm not sure. Have you tried Heaptrack with GCC 11 yet? I am thinking there may be an issue with the debug info that the compiler is generating, as I am seeing impossible stack traces in GDB while interactively debugging my own programs too. What I observe is that a stack frame will show as belonging to a leaf function that has already returned, and in fact the frame that called the leaf function is not represented separately in the stack trace, but rather the frame that shows as the leaf function *is* the frame that called the leaf function, and the information about the caller of the leaf function is absent from the stack trace. It is as though GCC is *overwriting* the source location information in the current stack frame when it invokes the (presumably inlined) leaf function and then forgets to restore it when it's finished with the leaf function. That would explain why my Heaptrack output is making no sense to me and has been utterly useless for tracking down a memory leak. -- You are receiving this mail because: You are watching all bug changes.
