|
From: Christoph B. <bar...@or...> - 2006-09-13 09:23:30
|
Hi, I currently use the version from trunk because of the fixes to my problems. Maybe the following problem is caused by my usage of trunk. Running callgrind_annotate on my result I get such messages: - Lots of warnings regarding jfi: WARNING: line 44364 malformed, ignoring line: 'jfi=(10) array.h' - Lots of uninitialized values in hash elements Use of uninitialized value in hash element at /lfs/user/bartosch/software/vg-test/bin/callgrind_annotate line 597, <INPUTFILE> line 44463. - Lots of uninitialized values in concatenation Use of uninitialized value in concatenation (.) or string at /lfs/user/bartosch/software/vg-test/bin/callgrind_annotate line 596, <INPUTFILE> line 51228 The profiled program runs on a amd64 box with valgrind for amd64. When I open the callgrind.out.pid file with kcachegrind (32bit version) on the amd64 box the profile is really strange. After the obligatory rearrangement of the windows one has functions that take more than 100% of the runtime. (see http://www.pontohonk.de/example/kcachegrind.png) When I open the profile on a i386 machine with suse 10.1 and its kcachegrind the file seems to look reasonable. Christoph |
|
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 |
|
From: Josef W. <Jos...@gm...> - 2006-09-13 11:49:35
|
On Wednesday 13 September 2006 13:33, Josef Weidendorfer wrote:
> On Wednesday 13 September 2006 11:23, Christoph Bartoschek wrote:
> > - Lots of warnings regarding jfi:
> >
> > WARNING: line 44364 malformed, ignoring
> > line: 'jfi=(10) array.h'
Does the following patch help (you can also
apply it to callgrind_annotate directly, without the
".in" suffix).
I just noted that the ignored line also adds an
"ID to filename" mapping, which could be the reason for
subsequent warnings you mentioned.
Josef
===================================================================
--- callgrind_annotate.in (Revision 6052)
+++ callgrind_annotate.in (Arbeitskopie)
@@ -634,6 +634,16 @@
} elsif (s/^(jump|jcnd)=//) {
#ignore jump information
+ } elsif (s/^jfi=(.*)$//) {
+ # side effect needed: possibly add compression mapping
+ uncompressed_name("fl",$1);
+ # ignore jump information
+
+ } elsif (s/^jfn=(.*)$//) {
+ # side effect needed: possibly add compression mapping
+ uncompressed_name("fn",$1);
+ # ignore jump information
+
} elsif (s/^totals:\s+//) {
#ignore
=========================================================
|
|
From: Christoph B. <bar...@or...> - 2006-09-13 12:01:44
|
Am Mittwoch, 13. September 2006 13:49 schrieb Josef Weidendorfer: > On Wednesday 13 September 2006 13:33, Josef Weidendorfer wrote: > > On Wednesday 13 September 2006 11:23, Christoph Bartoschek wrote: > > > - Lots of warnings regarding jfi: > > > > > > WARNING: line 44364 malformed, ignoring > > > line: 'jfi=(10) array.h' > > Does the following patch help (you can also > apply it to callgrind_annotate directly, without the > ".in" suffix). > I just noted that the ignored line also adds an > "ID to filename" mapping, which could be the reason for > subsequent warnings you mentioned. > > Josef Ok, with this patch there are no warnings. With cycle detection on, kcachegrind shows reasonable values on both machines. Now there is only the callgrind_control -i on error left. Greetings Christoph |