https://bugs.kde.org/show_bug.cgi?id=385127
--- Comment #7 from xse ---
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 :)
--
Yo
https://bugs.kde.org/show_bug.cgi?id=385127
--- Comment #6 from Josef Weidendorfer ---
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.
https://bugs.kde.org/show_bug.cgi?id=385127
Josef Weidendorfer changed:
What|Removed |Added
Status|CONFIRMED |RESOLVED
Resolution|---
https://bugs.kde.org/show_bug.cgi?id=385127
--- Comment #4 from xse ---
... 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
https://bugs.kde.org/show_bug.cgi?id=385127
--- Comment #3 from xse ---
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
https://bugs.kde.org/show_bug.cgi?id=385127
--- Comment #2 from xse ---
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
https://bugs.kde.org/show_bug.cgi?id=385127
Josef Weidendorfer changed:
What|Removed |Added
Status|UNCONFIRMED |CONFIRMED
Ever confirmed|0
