Hi, I was looking at kcachegrind, to have a look i compilled the most basic empty C program without any library that looks like this : int main(void) { return 0; } I tried compilling it using both gcc and clang, adding the "-g" option, and i used valgrind with "--dump-instr=yes --collect-jumps=yes --tool=callgrind" The issue is when trying to have a look at the bottom right "Machine Code" tab, on the "strcmp" function, kcachegrind segfault directly. I don't really know what i can add to help, hmm apparently i can't add multiple attachements when submitting a bug, what i'm gonna do is upload the related files... uname -a : Linux dev 4.12.13-1-ARCH #1 SMP PREEMPT Fri Sep 15 06:36:43 UTC 2017 x86_64 GNU/Linux valgrind --version : valgrind-3.13.0 gcc : 7.2.0 kcachegrind : 0.8.0kde (installed using pacman ) Here is a archive with the callgrind.out, the a.out and the code+binary used when segfault : http://s000.tinyupload.com/?file_id=41787805261408517736 Feel free to ask for more if you can't reproduce it, i might compille kcachegrind with debug flags and so on when i'll have time like tomorow or something.. Have a good day !
Thanks for detailed report und the *.out file! I actually can reproduce the segfault with strcmp on the machine code tab. This definitly should not happen. Will dig into this in the next days.
Awesome ! I was kinda affraid that i was using the whole thing wrong :) Be aware it does not happend every times. I somehow managed to reproduce the exact same procedure without any segfaults ( same callgrind.out file, same versions and everything ). Let says like about once in twenty times trying to load the machine code of that specific function there is no problem https://i.imgur.com/qX5JJtd.png Good luck looking into that :)
Eeeeh i can't seems to be able to edit a previous comment, so : When i manage to get kcachegrind to display the strcmp machine code and i close it, the next time i open it it's no longer displaying the entire strcmp machine code ( like if i close it on the strlen machine code for example and relaunch it, it comes back to where i was ). But when doing it with strcmp, i get that result https://i.imgur.com/YYOfcf9.png ( so it display twice the strcmp function in the left list, and the once were it puts me back is apparently only called one time and contain a small bit of asm, the "other" strcmp function, the one called 188 times is still there on top of the list. No idea if that can be usefull and if this is even understandable, i'm not
... sorry this bugtracker is a pain in the ass to use --' Anyway as you can see when i reload the program after closing it when it sucesfully manage to display strcmp's machine code, i noticed that the start adress given to objdump is different, that was basicly my point sorry i had to make 3 comments to say it..
Fixed in commit afb704ba99b0, branch Applications/17.08, and merged to master. That is, when Archlinux packs KDE 17.08.02 (next bug fix release), it should be fixed. Or compile it yourself, e.g. using mirror https://github.com/KDE/kcachegrind BTW, you do not have KDE dev libs installed, but can compile a pure-Qt version, using qmake + make.
BTW, the bug was due to going to std::sort instead of Qt's qSort in a few places. std::sort is more strict and requires strict ordering from the compare function. Otherwise, out-of-bound accesses could happen. I fixed this for just one case, but missed a few others... The issue with objdump using a wrong address (?) seems to be unrelated. If this still happens, can you open another bug report?
Woaw that was quick ! Good to know i'm gonna try that Qt version, i'm pretty sure the objdump issue was an effect of that first bug since it only appears when i played with the buggy function. Anyway thanks a lot :)