|
From: <aul...@mi...> - 2007-05-23 23:38:24
|
I have run into an problem with callgrind that cachegrind does not seem
to have. I have some code which is compiled (using gcc on Linux) into a
shared library. An application dlopens this library and makes various
calls into it. For some reason callgrind can't/won't annotate the files
I'm interested in this library, but cachegrind has no trouble with them.
I get no errors when I run valgrind --tool=3Dcallgrind <my program>
When I run callgrind_annotate I get the following errors:
Possible precedence problem on bitwise & operator at callgrind_annotate
line 870.
Use of uninitialized value in numeric lt (<) at callgrind_annotate line
1103.
Use of uninitialized value in numeric lt (<) at callgrind_annotate line
1114.
Use of uninitialized value in numeric lt (<) at callgrind_annotate line
1103.
Use of uninitialized value in numeric lt (<) at callgrind_annotate line
1114.
Then in my output I see something like this instead of my annotated
source:
------------------------------------------------------------------------
--------
-- Auto-annotated source: /full/path/to/file.cc
------------------------------------------------------------------------
--------
Ir=20
178,159,616 <counts for unidentified lines in /full/path/to/file.cc>
When I run cachegrind it has no trouble annotating the same sources,
using the same binary and library. I am using valgrind 3.2.3.
Any help would be greatly appreciated. Please let me know if I can
provide more information.
Thanks,
Ashley
|
|
From: Nicholas N. <nj...@cs...> - 2007-05-24 02:28:53
|
On Wed, 23 May 2007 aul...@mi... wrote: > I have run into an problem with callgrind that cachegrind does not seem > to have. I have some code which is compiled (using gcc on Linux) into a > shared library. An application dlopens this library and makes various > calls into it. For some reason callgrind can't/won't annotate the files > I'm interested in this library, but cachegrind has no trouble with them. Josef might be able to give more info, but the basic problem is caused by the dlopen'd library subsequently being dlclosed. Cachegrind handles this, but Callgrind does not -- all the information for the instructions in the library get merged into a single "???" entry. (Cachegrind used to do the same thing, and then I worked out a fix, but I think there was some reason why that fix wasn't appropriate for Callgrind.) A hacky possible workaround: can you avoid dlclosing the library? Nick |
|
From: <aul...@mi...> - 2007-05-24 14:29:11
|
Nick, Thank you for the fast reply! I commented out the dlclose, rebuilt, and callgrind works much better. It is still complaining about the "Possible precedence problem" but it seems to have done the real work anyway. Now I just hope I can remember this for the next time I use callgrind. At least it will be in the list archives now for me to find. :D Thanks again, Ashley -----Original Message----- From: Nicholas Nethercote [mailto:nj...@cs...]=20 Sent: Wednesday, May 23, 2007 8:29 PM To: aulwelling Cc: val...@li... Subject: Re: [Valgrind-users] Problems with callgrind_annotate On Wed, 23 May 2007 aul...@mi... wrote: > I have run into an problem with callgrind that cachegrind does not=20 > seem to have. I have some code which is compiled (using gcc on Linux) > into a shared library. An application dlopens this library and makes=20 > various calls into it. For some reason callgrind can't/won't annotate > the files I'm interested in this library, but cachegrind has no trouble with them. Josef might be able to give more info, but the basic problem is caused by the dlopen'd library subsequently being dlclosed. Cachegrind handles this, but Callgrind does not -- all the information for the instructions in the library get merged into a single "???" entry. (Cachegrind used to do the same thing, and then I worked out a fix, but I think there was some reason why that fix wasn't appropriate for Callgrind.) A hacky possible workaround: can you avoid dlclosing the library? Nick |
|
From: Josef W. <Jos...@gm...> - 2007-05-24 19:00:24
|
On Thursday 24 May 2007, aul...@mi... wrote:
> Nick,
>
> Thank you for the fast reply! I commented out the dlclose, rebuilt, and
> callgrind works much better.
Good.
> It is still complaining about the
> "Possible precedence problem" but it seems to have done the real work
> anyway.
The "uninitialized value" warnings are gone?
Can you try the following short patch to get rid of the warning?
==================================================
--- callgrind_annotate (Revision 6742)
+++ callgrind_annotate (Arbeitskopie)
@@ -867,7 +867,7 @@
if ($summary_CC->[$sort_order[$i]] >0) {
$prop = $prop / $summary_CC->[$sort_order[$i]];
}
- $reached_all_thresholds &= ($prop >= $thresholds[$i]);
+ $reached_all_thresholds &&= ($prop >= $thresholds[$i]);
}
last if $reached_all_thresholds;
==================================================
It seems I failed to forward port this from cachegrind/cg_annotate ;-)
> Now I just hope I can remember this for the next time I use callgrind.
> At least it will be in the list archives now for me to find. :D
Yes, probably worth mentioning in the manual
(Or do something about this).
> On Wed, 23 May 2007 Nicholas Nethercote wrote:
> Josef might be able to give more info, but the basic problem is caused
> by the dlopen'd library subsequently being dlclosed. Cachegrind handles
> this, but Callgrind does not -- all the information for the instructions
> in the library get merged into a single "???" entry. (Cachegrind used
> to do the same thing, and then I worked out a fix, but I think there was
> some reason why that fix wasn't appropriate for Callgrind.)
The issue is that at time of profile writing, debug info for dlclosed
libraries is not available anymore.
Cachegrind now associates event counters to source line numbers already
at instrumentation time. Callgrind instead associates counters more or
less to instruction addresses, to be able to write the counters at
instruction granularity into the profile file.
But this difference is not really an excuse - I should be able to
retrieve source line numbers at instrumentation time, too (at the cost
of additional memory use).
I will look into this.
> A hacky possible workaround: can you avoid dlclosing the library?
Or just write out the profile file before dlclosing:
valgrind --tool=callgrind --dump-before=dlclose ....
Oh, sorry.
There is no command line tool to merge the profiles :-(
You have to use KCachegrind to load the files instead.
Josef
|
|
From: <aul...@mi...> - 2007-05-24 20:28:52
|
Josef,
See my comments inline. :)
> -----Original Message-----
> From: Josef Weidendorfer [mailto:Jos...@gm...]=20
> Sent: Thursday, May 24, 2007 1:00 PM
> To: val...@li...
> Cc: aulwelling; Nicholas Nethercote
> Subject: Re: [Valgrind-users] Problems with callgrind_annotate
>=20
> On Thursday 24 May 2007, aul...@mi... wrote:
> > Nick,
> >=20
> > Thank you for the fast reply! I commented out the dlclose,=20
> rebuilt,=20
> > and callgrind works much better.
>=20
> Good.
>=20
> > It is still complaining about the
> > "Possible precedence problem" but it seems to have done the=20
> real work=20
> > anyway.
>=20
> The "uninitialized value" warnings are gone?
Yes. They show up when I dlclose the library, and go away when I don't
dlclose the library.
> Can you try the following short patch to get rid of the warning?
>=20
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> --- callgrind_annotate (Revision 6742)
> +++ callgrind_annotate (Arbeitskopie)
> @@ -867,7 +867,7 @@
> if ($summary_CC->[$sort_order[$i]] >0) {
> $prop =3D $prop / $summary_CC->[$sort_order[$i]];
> }
> - $reached_all_thresholds &=3D ($prop >=3D =
$thresholds[$i]);
> + $reached_all_thresholds &&=3D ($prop >=3D =
$thresholds[$i]);
> }
> last if $reached_all_thresholds;=20
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
>=20
> It seems I failed to forward port this from cachegrind/cg_annotate ;-)
=20
Yes, this got rid of the precedence problem. I'll incorporate this
change into our copy of callgrind_annotate.
> > Now I just hope I can remember this for the next time I use=20
> callgrind.
> > At least it will be in the list archives now for me to find. :D
>=20
> Yes, probably worth mentioning in the manual (Or do something=20
> about this).
>=20
> > On Wed, 23 May 2007 Nicholas Nethercote wrote:
> > Josef might be able to give more info, but the basic=20
> problem is caused=20
> > by the dlopen'd library subsequently being dlclosed. Cachegrind=20
> > handles this, but Callgrind does not -- all the information for the=20
> > instructions in the library get merged into a single "???" entry. =20
> > (Cachegrind used to do the same thing, and then I worked out a fix,=20
> > but I think there was some reason why that fix wasn't=20
> appropriate for=20
> > Callgrind.)
>=20
> The issue is that at time of profile writing, debug info for=20
> dlclosed libraries is not available anymore.
>=20
> Cachegrind now associates event counters to source line=20
> numbers already at instrumentation time. Callgrind instead=20
> associates counters more or less to instruction addresses, to=20
> be able to write the counters at instruction granularity into=20
> the profile file.
> But this difference is not really an excuse - I should be=20
> able to retrieve source line numbers at instrumentation time,=20
> too (at the cost of additional memory use).
>=20
> I will look into this.
>=20
> > A hacky possible workaround: can you avoid dlclosing the library?
>=20
> Or just write out the profile file before dlclosing:
>=20
> valgrind --tool=3Dcallgrind --dump-before=3Ddlclose ....
>=20
> Oh, sorry.
> There is no command line tool to merge the profiles :-( You=20
> have to use KCachegrind to load the files instead.
>=20
> Josef
I'd love to use KCachegrind, but my system doesn't have the proper
packages installed. However, it looks like the --dump-before option
might work for me since our library is unloaded near the end of the
process, and all the code I'm interested in is in the same library.
I will experiment some more with the valgrind options but at this point
I can easily work around the issue with our code. I really appreciate
all the feedback. What a great community this is!
Thanks,
Ashley
|