kcachegrind fails to locate a path specified in "fl" field of callgrind log if the path contains any non-latin characters. Reproducible: Always Steps to Reproduce: 1. Place any source code in a directory named with non-latin characters. Compile an executable. 2. Run the executable under valgrind to produce callgrind log. 3. Open the log with kcachegrind and go to "Source Code" tab. Actual Results: Displayed file path contains garbage instead of non-latin characters, and message "source file cannot be found" are shown instead of file contents. The problem is in implementation of operator FixString::QString(). It should call QString::fromLocal8Bit(_str,_len), not QString::fromLatin1(_str,_len).
Thanks for hunting this down. While I can reproduce it on my system (Ubuntu 13.04, uses UTF-8), and your suggestion fixes the problem, I am not sure I understand the consequences. Let me try to understand this (not sure everything is true): (1) encodings for file names use the encoding of the locale from the system (for me UTF-8) (2) the compiler just will use the byte sequence it gets from the command line to access files and generating the debug information. Ie. it implicitly uses the locale again for encoding. (2) Callgrind just use the raw byte sequences found in the debug information for writing the profile dump. Thus, the dump now implicitly has the locale encoding of the system where the executable was compiled (e.g. for me, the "file" command detects it as UTF-8 encoded). (4) KCachegrind wants to store source file names into QString. By using "QString::fromLocal8Bit", we make sure that the locale of the system is used to convert it to a QString (which internally uses Unicode). (5) When accessing a source file, QFile constructor with the file name is used. It probably again uses the systems locale to convert from the internal QString representation to the name for opening the file. From this reasoning, it is clear that "QString::fromLatin1" is wrong with any locale different from Latin1. However, "QString::fromLocal8Bit" works only if the locale of the system where the executable was compiled is the same as the one where KCachegrind is run to visualize this profile (the locale of the system where callgrind was running does not really matter). I assume that this is true most of the time. Thus, your fix is more like best-effort: "it probably works most of the time". The real fix would be to define a header field in the format to specify the encoding of file names, and make callgrind to fill out this information. KCachegrind should understand this field and use the right convertion. However, I do not see how Callgrind or Valgrind can detect the encoding of file names from DWARF debug info... Thus I am fine with the fix. Fixed in git revision 93c5291a61.