Version: unspecified (using KDE 4.7.2) OS: FreeBSD I get this on FreeBSD: no matter what function I select and no matter what event type I select, I always get this message in place of the Call Graph: There is no call graph available for function 'xxx' because it has no cost of the selected event type Even though the functions do have non zero costs. I think this is probably a FreeBSD issue, as I saw this working in linux before many times with earlier kcachegrind versions. Reproducible: Didn't try Steps to Reproduce: n/a Actual Results: n/a Expected Results: n/a n/a
Is this kcachegrind from the KDE 4.7.2 release? Without a way to reproduce, I can do nothing. Perhaps it does work if you remove the configuration, ie. cd ~/.kde/share/config mv kcachegrindrc kcachegrindrc.orig and restart? If this is the case, I would be interested in this configuration file and the one you try to load where you see the bug.
Deleting configuration doesn't help, issue stays the same. -- Here is the kcachegrind output in hopes this contains some clue -- kcachegrind(38602)/KSharedDataCache ensureFileAllocated: This system misses support for posix_fallocate() -- ensure this partition has room for at least 10547296 bytes. kcachegrind(38602)/KSharedDataCache: Unable to find an appropriate lock to guard the shared cache. This *should* be essentially impossible. :( kcachegrind(38602)/KSharedDataCache: Unable to perform initial setup, this system probably does not really support process-shared pthreads or semaphores, even though it claims otherwise. kcachegrind(38602)/KSharedDataCache: Unable to unmap shared memory segment 0x80a2e7000 CallGraphView::refresh CallGraphView::refresh: Started process 0x80e3e4c80, 'dot -Tplain' CallGraphView::readDotOutput: QProcess 0x80e3e4c80 CallGraphView::dotExited: QProcess 0x80e3e4c80 Warning: Unknown function 'F80a556e08' ?! Warning: Unknown function 'F80cbf6508' ?! Warning: Unknown function 'F81b17ea00' ?! Unknown edge ' "F80cbf6508" '-' "F80a556e08" ' from dot ( "/tmp/qt_temp.c38602" : 5 ) Unknown edge ' "F81b17ea00" '-' "F80cbf6508" ' from dot ( "/tmp/qt_temp.c38602" : 6 ) CallGraphView::refresh CallGraphView::refresh: Started process 0x80e3e4e70, 'dot -Tplain' CallGraphView::readDotOutput: QProcess 0x80e3e4e70 CallGraphView::dotExited: QProcess 0x80e3e4e70 Warning: Unknown function 'F80a598a08' ?! Warning: Unknown function 'F8138bc308' ?! Warning: Unknown function 'F8139b0e08' ?! Unknown edge ' "F8138bc308" '-' "F8139b0e08" ' from dot ( "/tmp/qt_temp.Q38602" : 5 ) Unknown edge ' "F8139b0e08" '-' "F80a598a08" ' from dot ( "/tmp/qt_temp.Q38602" : 6 )
Hmm... I remember some bug fix for the dot parser in the call graph view. Perhaps that causes this problem. Thas was r1120761 in the KDE SVN, see http://websvn.kde.org/?view=revision&revision=1120761 You could try to revert that and see if it works afterwards.
revision=1120761 replaced (long) with (qptrdiff), reverting this change didn't help. Changing (long) to (long long) also didn't help. Now I am thinking if this is the problem caused by 64-bit pointers? On FreeBSD amd64 pointers are 64-bit by default, even for small processes. Is it possible that kcachegrind assumes 32-bit pointers and fails for this reason?
Support of 64-bit pointers was exactly was r1120761 was about: on 64bit, sizeof(qptrdiff) should be 8 byte, and the complete addresses should be used. For the 2D layout of the call graph, KCachegrind calls "dot" in the background. To identify a function object, it uses the pointer address of the object as hex number for the node names to the "dot" input. In the generated output of dot, the node names allow to relate the positioned nodes back to the function objects. And somehow, the latter does not work for you. E.g. "Warning: Unknown function 'F80a598a08' ?!" is printed by the parser of the output from dot. It warns that it can not find a function object at address 0xF80a598a08, which actually should exist. You could try to find the problem using the debugger, both looking at how the data looks that is sent to "dot" (in GraphExporter::writeDot), check if the pointer addresses are valid, and check this against the output of dot (/tmp/qt_temp.Q38602 above). If that looks fine, the bug still could be in the parser which is printing out above warnings...
Created attachment 64925 [details] dot command input
Created attachment 64926 [details] dot comnmand output
I was debugging the case, but couldn't understand why dot parser doesn't like the output. I am attaching both input and output of 'dot -Tplain' command here. kcachegrind is complaining on many (or all) node commands in the dot output.
I have graphviz-2.28.0. It's possible that dot output has different format compared to what kcachegrind was tested against (version is too old or too new). I saw such variations in dot output in the past.
(In reply to comment #9) > I have graphviz-2.28.0. > It's possible that dot output has different format compared to what kcachegrind > was tested against (version is too old or too new). I saw such variations in > dot output in the past. That could be a reason. Hmm. The "plain" format was really stable in the past. I never saw a problem there. From a first look, your input/output looks fine, but I'll check in more detail.
Oops. I think I see the problem. In callgraphview.cpp, search for "toUInt" (in GraphExporter::toFunc), and replace it with "toULongLong". Your pointers have 9 hex digits, and that does not work with toUInt(), which is 32 bit. Does it work this way? This really is ugly, and can crash if dot changes slightly the names. I will come up with a nicer fix.
Yes, toULongLong fixed the problem.
Fixed in r1261035 (simple fix; more elaborated one comes later...)