Bug 380985

Summary:	Incorrect library used when app relies on rpath
Product:	[Applications] Heaptrack	Reporter:	Thomas McGuire <mcguire>
Component:	general	Assignee:	Milian Wolff <mail>
Status:	RESOLVED NOT A BUG
Severity:	normal
Priority:	NOR
Version First Reported In:	unspecified
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description Thomas McGuire 2017-06-08 18:29:29 UTC

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.

Comment 1 Milian Wolff 2017-06-09 11:49:27 UTC

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.

Comment 2 Thomas McGuire 2017-06-28 13:55:18 UTC

Upps, this was a user problem, the executable accidentally loaded the wrong Qt...