|
From: Josef W. <Jos...@in...> - 2006-09-13 11:33:53
|
On Wednesday 13 September 2006 11:23, Christoph Bartoschek wrote: > I currently use the version from trunk because of the fixes to my problem= s.=20 > Maybe the following problem is caused by my usage of trunk. Probably not; all the fixes should no also be in the 3.2 branch (to become 3.2.1). > Running callgrind_annotate on my result I get such messages: >=20 > - Lots of warnings regarding jfi: >=20 > WARNING: line 44364 malformed, ignoring > line: 'jfi=3D(10) array.h' "jfi" is used when the source file changes in a jump between jump source and jump target. As callgrind_annotate does not show jump arrows in its annotation at all, this information is not needed, so nothing to really worry about. But of course you are right, callgrind_annotate should not complain about such lines. =20 > - Lots of uninitialized values in hash elements >=20 > Use of uninitialized value in hash element=20 > at /lfs/user/bartosch/software/vg-test/bin/callgrind_annotate line 597,=20 > <INPUTFILE> line 44463. This seems to be about "%all_ind_CCs". Seems to be similar to the code of cg_annotate. > - Lots of uninitialized values in concatenation >=20 > Use of uninitialized value in concatenation (.) or string=20 > at /lfs/user/bartosch/software/vg-test/bin/callgrind_annotate line 596,=20 > <INPUTFILE> line 51228 Hmm. That's strange. Both $curr_file and $curr_fn should be defined. Can you send me the profile data in private? > The profiled program runs on a amd64 box with valgrind for amd64. When I = open=20 > the callgrind.out.pid file with kcachegrind (32bit version) on the amd64 = box=20 > the profile is really strange. After the obligatory rearrangement of the= =20 > windows one has functions that take more than 100% of the runtime. (see=20 > http://www.pontohonk.de/example/kcachegrind.png) There is nothing strange about. This is the reason why cycle detection is needed; otherwise, you can see >100% cost attributed to calls in recursive cycles (with cycle detection on, display of inner-cycle-calls gets suppress= ed as it is useless). The reason that cycle detection can be switched off is, that even when KCac= hegrind detects a cycle, such inter-cycle call costs still can be useful (e.g. when the reason for the cycle is only marginal). =20 > When I open the profile on a i386 machine with suse 10.1 and its kcachegr= ind=20 > the file seems to look reasonable. =46or the same profile data and "cycle detection" mode in KCachegrind? That seems strange, and could be a bug in KCachegrind. Josef >=20 > Christoph >=20 > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job ea= sier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat= =3D121642 > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users >=20 >=20 =2D-=20 Dr. Josef Weidendorfer LRR-TUM (Bode) - Raum 01.06.056 - Tel. +49 / (0)89 / 289 - 18454 Institut f=FCr Informatik, Technische Universit=E4t M=FCnchen |