| Summary: | kcachegrind looses track of callers-callees, duplicating entries. (xdebug php profile) | ||
|---|---|---|---|
| Product: | [Developer tools] kcachegrind | Reporter: | jay <jay> |
| Component: | general | Assignee: | Josef Weidendorfer <josef.weidendorfer> |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | normal | CC: | fmaz008, kde, sebastian |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Attachments: |
{main} selected
Double clicked first callee twin without callers tested cachegrind file |
||
Created attachment 53268 [details]
Double clicked first callee
Created attachment 53269 [details]
twin without callers
Created attachment 53270 [details]
tested cachegrind file
http://websvn.kde.org/?view=revision&revision=1136842 http://websvn.kde.org/trunk/KDE/kdesdk/kcachegrind/libcore/tracedata.cpp?r1=1136842&r2=1136841&pathrev=1136842 This commit is responsible. Thanks for the analysis. Actually, the supplied cachegrind file seems buggy to me. It only specifies the source file name for functions, but not for call targets. If you look up the format specification at http://kcachegrind.sourceforge.net/html/CallgrindFormat.html in the example of chapter 1.4 (extended example), you see something like ... cfl=file2.c cfn=func2 calls=3 20 16 400 ... which specifies a call to func2, which is defined in line 16 of source file "file2.c". In your file (supposedly written by xdebug), the are no lines at all beginning with "cfl=", so actually, all calls target functions with unknown source. Previously, functions with same name but in different source files were merged, which made it look like that the xdebug output is fine. But actually, this merge behavior is broken because at least in C, you can define distinct functions with the same name in different files, if the definitions are "static" (ie. scope is file-local). So, this should be a bug report for xdebug. I do not really see a way to both have to old broken and the new correct behavior. *** Bug 265886 has been marked as a duplicate of this bug. *** xdebug bug is not moving. Would it please be possible, at least, put a switch into settings, which behaviour to use ? - "correct new" :: "incorrect old - for xdebug" (In reply to comment #8) > xdebug bug is not moving. I am discussing the issue with Derick Rethans at the moment. I am sure that it will "move" soon. (In reply to comment #9) > I am discussing the issue with Derick Rethans at the moment. I am sure that it > will "move" soon. Great! It was my suggestion to push xdebug about this. I will add a paragraph to the Callgrind format specification about this. (In reply to comment #8) > Would it please be possible, at least, put a switch into settings, > which behaviour to use ? - "correct new" :: "incorrect old - for xdebug" As I said in a duplicate of this bug, it even should be possible to detect xdebug output when seeing "version: 0.9.7". I am not sure what "0.9.7" here should be, but it is definitely wrong. The field is supposed to provide the version of the Callgrind format used in the file, and up to now, only version "1" is valid. Can this issue be forwarded to the xdebug guys, also? It would be very good to add a creator string, however. This can include version information, e.g. "creator: xdebug 0.9.7", and would allow to easier add workarounds for specific if needed. If I find time, I can add the workaround via detection of "version: 0.9.7". Neverless, this should be corrected in xdebug, also. (In reply to comment #10) > As I said in a duplicate of this bug, it even should be possible to detect > xdebug output when seeing "version: 0.9.7". I am not sure what "0.9.7" here > should be, but it is definitely wrong. The field is supposed to provide > the version of the Callgrind format used in the file, and up to now, only > version "1" is valid. Can this issue be forwarded to the xdebug guys, also? > It would be very good to add a creator string, however. This can include > version information, e.g. "creator: xdebug 0.9.7", and would allow to easier > add workarounds for specific if needed. > > If I find time, I can add the workaround via detection of "version: 0.9.7". > Neverless, this should be corrected in xdebug, also. Forwarded to Xdebug developer. I'm not sure if you need additional informations but I've some screenshots that might help: http://img46.imageshack.us/img46/2226/kcachegrind123.png Notice the location: (unknown) (In reply to comment #12) > Notice the location: (unknown) Yes. That is the effect of Xdebug output not having any lines starting with "cfl=", which would specify the source location of a call target (see comment #5). As I said, this is a misuse of too relaxed merging of symbols in previous versions of KCachegrind. Making this more strict, which actually fixed a real bug with Callgrind/C code (I will not revert that fix for Xdebug), made this wrong Xdebug output to have this visible side effect. Hi! For your information, this is now fixed in Xdebug's SVN (and ready to go into 2.1.1). cheers, Derick Cool, thanks! |
Created attachment 53267 [details] {main} selected Version: unspecified (using KDE 4.5.1) OS: Linux Normaly (kcachegrind 0.5.1) I can follow application flow from {main} by going thru callees or source code. In 0.6, clicking on a callee switches to one, without child callees. Twin of it in left list, has Callees but no Callers. Images attached tell more than text. Reproducible: Always Steps to Reproduce: Open cachegrind file generated by xdebug (php). kubuntu maverick. Happens on system version and compiled version. Happens also on ubuntu lucid with kde 4.5 from ppa.