I was using heaptrack on an app that uses a Qt4 installed in /home/thomas/install/opt/qt-4-desktop. That application uses rpath to find the Qt4 libraries without the need to set LD_LIBRARY_PATH. My LD_LIBRARY_PATH actually had the Qt libraries from /usr/lib64 in them. heaptrack used the incorrect Qt from /usr/lib64, resulting in backtraces with lots of unresolved symbols. I spotted that the wrong library was used in the tooltip of the flame graph, which shows the library of an entry, As a workaround, I changed my LD_LIBRARY_PATH. However I think heaptrack should do the correct thing and follow the rpath, as otherwise the behaviour can be highly confusing if one doesn't spot the incorrect library by chance.
interesting, that's pretty odd! can you share a setup with me that I can use to reproduce this? Did your setup maybe use split debug symbols in a separate file? I'm having a hard time figuring out how this can happen, conceptually. The mappings contain absolute paths to the actual files that are being used after all.
Upps, this was a user problem, the executable accidentally loaded the wrong Qt...