|
From: Justace C. <pro...@co...> - 2005-07-12 03:09:56
|
Valgrinders...
I was working on a program and then decided to look into using
kcachegrind to help me profile and generate call graphs. When running I
noticed that there was a bunch of numbers where I thought there should
have been function or method names. I looked everywhere I could and can
not find a way to fix the problem. So, I wrote a very small and silly
program to see if that would fix it, nope, same problem. I am using gcc
3.4.4 on Gentoo and using the "-ggdb" flag only for my compiles and
links. I also tried a variety of combinations between -p, -pg, -g,
-g3... I am including in this email a tarball of the test code to show
what I mean along with with a picture of the desktop showing the
offending program. I am really not sure where to go with this. The
tools will be un-usable if I can not tell which functions are which.
Thanks in advance for any help that you can provide.
Justace clutter
The attachements were too big so I posted them to a web address.
http://clued0.fnal.gov/~prophecy/valgrind
P.S. Sorry for the repost
|
|
From: Josef W. <Jos...@in...> - 2005-07-12 09:54:51
|
Hi, On Tuesday 12 July 2005 00:09, Justace Clutter wrote: > Valgrinders... > > I was working on a program and then decided to look into using > kcachegrind to help me profile and generate call graphs. When running I > noticed that there was a bunch of numbers where I thought there should > have been function or method names. I looked everywhere I could and can > not find a way to fix the problem. So, I wrote a very small and silly > program to see if that would fix it, nope, same problem. I am using gcc=20 > 3.4.4 on Gentoo and using the "-ggdb" flag only for my compiles and > links. Sorry, I just can not see your problem in the small test you provided. The= =20 only thing I see is that system libraries on your system are stripped. If you look only at the symbols from your binary (Grouping by ELF object,=20 select "test"), almost all entries in the list have function names and are= =20 not hex numbers. So your compiler is producing the debug info, and valgrind= =20 is loading this info. The entries without names are compiler generated=20 without symbol info. Regarding the screen shot, it actually looks like there are quite a few=20 functions without symbol info. Either the compiler does not provide debug=20 info (seems unlikely), the binary is somehow stripped afterwards (you shoul= d=20 recheck with "nm" if expected symbols are actually provided in the binary),= =20 or the valgrind debug info reader is buggy. Unfortunately I can not reproduce the problem, and as said above, the small= =20 test code seems fine. Can you give me a hex number there where a symbol nam= e=20 (from the "test" binary) should show up? Or generate a test case where you= =20 can show this? Josef > I also tried a variety of combinations between -p, -pg, -g,=20 > -g3... I am including in this email a tarball of the test code to show > what I mean along with with a picture of the desktop showing the > offending program. I am really not sure where to go with this. The > tools will be un-usable if I can not tell which functions are which. > Thanks in advance for any help that you can provide. > > Justace clutter > > The attachements were too big so I posted them to a web address. > > http://clued0.fnal.gov/~prophecy/valgrind > > P.S. Sorry for the repost > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the 'Do More With Dual!' webinar > happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest > in dual core and dual graphics technology at this free one hour event > hosted by HP, AMD, and NVIDIA. To register visit > http://www.hp.com/go/dualwebinar > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users =2D-=20 Dr. Josef Weidendorfer LRR-TUM (Bode) - Raum 01.06.056 - Tel. +49 / (0)89 / 289 - 18454 Institut f=C3=BCr Informatik, Technische Universit=C3=A4t M=C3=BCnchen |
|
From: Justace C. <pro...@co...> - 2005-07-12 13:35:52
|
Well, I looked at the actual binary for the original program with "nm -a". I have included the output with this email, it is small enough. I have been able to cross reference a few of the hex numbers to symbols in the file. For example: 0x0804F304 -> main 0x0804F76C -> _ZN6TreffyC1Ev 0x0804FA84 -> _ZV6Treffy4TestEv These correspond to the functions main, Treffy constructor, and Treffy::Test. So it seems that there is some name mangling. Does this help to shed light on the problem? Thanks for the help... Justace On Tue, 2005-07-12 at 11:54 +0200, Josef Weidendorfer wrote: > Hi, > > On Tuesday 12 July 2005 00:09, Justace Clutter wrote: > > Valgrinders... > > > > I was working on a program and then decided to look into using > > kcachegrind to help me profile and generate call graphs. When running I > > noticed that there was a bunch of numbers where I thought there should > > have been function or method names. I looked everywhere I could and can > > not find a way to fix the problem. So, I wrote a very small and silly > > program to see if that would fix it, nope, same problem. I am using gcc > > 3.4.4 on Gentoo and using the "-ggdb" flag only for my compiles and > > links. > > Sorry, I just can not see your problem in the small test you provided. The > only thing I see is that system libraries on your system are stripped. > If you look only at the symbols from your binary (Grouping by ELF object, > select "test"), almost all entries in the list have function names and are > not hex numbers. So your compiler is producing the debug info, and valgrind > is loading this info. The entries without names are compiler generated > without symbol info. > > Regarding the screen shot, it actually looks like there are quite a few > functions without symbol info. Either the compiler does not provide debug > info (seems unlikely), the binary is somehow stripped afterwards (you should > recheck with "nm" if expected symbols are actually provided in the binary), > or the valgrind debug info reader is buggy. > > Unfortunately I can not reproduce the problem, and as said above, the small > test code seems fine. Can you give me a hex number there where a symbol name > (from the "test" binary) should show up? Or generate a test case where you > can show this? > > Josef > > > I also tried a variety of combinations between -p, -pg, -g, > > -g3... I am including in this email a tarball of the test code to show > > what I mean along with with a picture of the desktop showing the > > offending program. I am really not sure where to go with this. The > > tools will be un-usable if I can not tell which functions are which. > > Thanks in advance for any help that you can provide. > > > > Justace clutter > > > > The attachements were too big so I posted them to a web address. > > > > http://clued0.fnal.gov/~prophecy/valgrind > > > > P.S. Sorry for the repost > > > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by the 'Do More With Dual!' webinar > > happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest > > in dual core and dual graphics technology at this free one hour event > > hosted by HP, AMD, and NVIDIA. To register visit > > http://www.hp.com/go/dualwebinar > > _______________________________________________ > > Valgrind-users mailing list > > Val...@li... > > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Josef W. <Jos...@in...> - 2005-07-12 14:25:10
|
On Tuesday 12 July 2005 10:35, you wrote: > Well, > > I looked at the actual binary for the original program with "nm -a". I > have included the output with this email, it is small enough. I can not see it ;-) Can you also provide the output of valgrind --tool=3Dnone --trace-symtab=3Dyes <yourprogram> Of course the best would be to have a binary showing the problem. Which version of valgrind are you using? Josef > I have=20 > been able to cross reference a few of the hex numbers to symbols in the > file. For example: > > 0x0804F304 -> main > 0x0804F76C -> _ZN6TreffyC1Ev > 0x0804FA84 -> _ZV6Treffy4TestEv > > These correspond to the functions main, Treffy constructor, and > Treffy::Test. So it seems that there is some name mangling. Does this > help to shed light on the problem? > > Thanks for the help... > > Justace > > On Tue, 2005-07-12 at 11:54 +0200, Josef Weidendorfer wrote: > > Hi, > > > > On Tuesday 12 July 2005 00:09, Justace Clutter wrote: > > > Valgrinders... > > > > > > I was working on a program and then decided to look into using > > > kcachegrind to help me profile and generate call graphs. When running > > > I noticed that there was a bunch of numbers where I thought there > > > should have been function or method names. I looked everywhere I cou= ld > > > and can not find a way to fix the problem. So, I wrote a very small > > > and silly program to see if that would fix it, nope, same problem. I = am > > > using gcc 3.4.4 on Gentoo and using the "-ggdb" flag only for my > > > compiles and links. > > > > Sorry, I just can not see your problem in the small test you provided. > > The only thing I see is that system libraries on your system are > > stripped. If you look only at the symbols from your binary (Grouping by > > ELF object, select "test"), almost all entries in the list have function > > names and are not hex numbers. So your compiler is producing the debug > > info, and valgrind is loading this info. The entries without names are > > compiler generated without symbol info. > > > > Regarding the screen shot, it actually looks like there are quite a few > > functions without symbol info. Either the compiler does not provide deb= ug > > info (seems unlikely), the binary is somehow stripped afterwards (you > > should recheck with "nm" if expected symbols are actually provided in t= he > > binary), or the valgrind debug info reader is buggy. > > > > Unfortunately I can not reproduce the problem, and as said above, the > > small test code seems fine. Can you give me a hex number there where a > > symbol name (from the "test" binary) should show up? Or generate a test > > case where you can show this? > > > > Josef > > > > > I also tried a variety of combinations between -p, -pg, -g, > > > -g3... I am including in this email a tarball of the test code to sh= ow > > > what I mean along with with a picture of the desktop showing the > > > offending program. I am really not sure where to go with this. The > > > tools will be un-usable if I can not tell which functions are which. > > > Thanks in advance for any help that you can provide. > > > > > > Justace clutter > > > > > > The attachements were too big so I posted them to a web address. > > > > > > http://clued0.fnal.gov/~prophecy/valgrind > > > > > > P.S. Sorry for the repost > > > > > > > > > > > > > > > ------------------------------------------------------- > > > This SF.Net email is sponsored by the 'Do More With Dual!' webinar > > > happening July 14 at 8am PDT/11am EDT. We invite you to explore the > > > latest in dual core and dual graphics technology at this free one hour > > > event hosted by HP, AMD, and NVIDIA. To register visit > > > http://www.hp.com/go/dualwebinar > > > _______________________________________________ > > > Valgrind-users mailing list > > > Val...@li... > > > https://lists.sourceforge.net/lists/listinfo/valgrind-users =2D-=20 Dr. Josef Weidendorfer LRR-TUM (Bode) - Raum 01.06.056 - Tel. +49 / (0)89 / 289 - 18454 Institut f=C3=BCr Informatik, Technische Universit=C3=A4t M=C3=BCnchen |
|
From: Justace C. <pro...@co...> - 2005-07-12 14:52:05
|
Just as a side note I also decided to post the binary file treffytng at the same location. Justace On Tue, 2005-07-12 at 16:24 +0200, Josef Weidendorfer wrote: > On Tuesday 12 July 2005 10:35, you wrote: > > Well, > > > > I looked at the actual binary for the original program with "nm -a". I > > have included the output with this email, it is small enough. > > I can not see it ;-) > Can you also provide the output of > valgrind --tool=none --trace-symtab=yes <yourprogram> > > Of course the best would be to have a binary showing the problem. > > Which version of valgrind are you using? > > Josef > > > I have > > been able to cross reference a few of the hex numbers to symbols in the > > file. For example: > > > > 0x0804F304 -> main > > 0x0804F76C -> _ZN6TreffyC1Ev > > 0x0804FA84 -> _ZV6Treffy4TestEv > > > > These correspond to the functions main, Treffy constructor, and > > Treffy::Test. So it seems that there is some name mangling. Does this > > help to shed light on the problem? > > > > Thanks for the help... > > > > Justace > > > > On Tue, 2005-07-12 at 11:54 +0200, Josef Weidendorfer wrote: > > > Hi, > > > > > > On Tuesday 12 July 2005 00:09, Justace Clutter wrote: > > > > Valgrinders... > > > > > > > > I was working on a program and then decided to look into using > > > > kcachegrind to help me profile and generate call graphs. When running > > > > I noticed that there was a bunch of numbers where I thought there > > > > should have been function or method names. I looked everywhere I could > > > > and can not find a way to fix the problem. So, I wrote a very small > > > > and silly program to see if that would fix it, nope, same problem. I am > > > > using gcc 3.4.4 on Gentoo and using the "-ggdb" flag only for my > > > > compiles and links. > > > > > > Sorry, I just can not see your problem in the small test you provided. > > > The only thing I see is that system libraries on your system are > > > stripped. If you look only at the symbols from your binary (Grouping by > > > ELF object, select "test"), almost all entries in the list have function > > > names and are not hex numbers. So your compiler is producing the debug > > > info, and valgrind is loading this info. The entries without names are > > > compiler generated without symbol info. > > > > > > Regarding the screen shot, it actually looks like there are quite a few > > > functions without symbol info. Either the compiler does not provide debug > > > info (seems unlikely), the binary is somehow stripped afterwards (you > > > should recheck with "nm" if expected symbols are actually provided in the > > > binary), or the valgrind debug info reader is buggy. > > > > > > Unfortunately I can not reproduce the problem, and as said above, the > > > small test code seems fine. Can you give me a hex number there where a > > > symbol name (from the "test" binary) should show up? Or generate a test > > > case where you can show this? > > > > > > Josef > > > > > > > I also tried a variety of combinations between -p, -pg, -g, > > > > -g3... I am including in this email a tarball of the test code to show > > > > what I mean along with with a picture of the desktop showing the > > > > offending program. I am really not sure where to go with this. The > > > > tools will be un-usable if I can not tell which functions are which. > > > > Thanks in advance for any help that you can provide. > > > > > > > > Justace clutter > > > > > > > > The attachements were too big so I posted them to a web address. > > > > > > > > http://clued0.fnal.gov/~prophecy/valgrind > > > > > > > > P.S. Sorry for the repost > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > This SF.Net email is sponsored by the 'Do More With Dual!' webinar > > > > happening July 14 at 8am PDT/11am EDT. We invite you to explore the > > > > latest in dual core and dual graphics technology at this free one hour > > > > event hosted by HP, AMD, and NVIDIA. To register visit > > > > http://www.hp.com/go/dualwebinar > > > > _______________________________________________ > > > > Valgrind-users mailing list > > > > Val...@li... > > > > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Justace C. <pro...@co...> - 2005-07-12 14:48:53
|
Ok.. So the valgrind version that I am running is valgrind-2.4.0. This is all compiled with gcc-3.4.4 under gentoo linux. The valgrind is a dependency of kcachegrind which of course requires callgrind. So, I forgot to attach the zip file last, sorry. Ok, so now I have generated the outputs that you were looking for. I have placed them at that last http address. For reference it is: http://clued0.fnal.gov/~prophecy/valgrind nm -a treffytng -> symbols.gz valgrind --tool=none --trace-symtab=yes ./treffytng -> valgrind_output callgrind ./treffytng -> callgrind.out.13226 Justace On Tue, 2005-07-12 at 16:24 +0200, Josef Weidendorfer wrote: > On Tuesday 12 July 2005 10:35, you wrote: > > Well, > > > > I looked at the actual binary for the original program with "nm -a". I > > have included the output with this email, it is small enough. > > I can not see it ;-) > Can you also provide the output of > valgrind --tool=none --trace-symtab=yes <yourprogram> > > Of course the best would be to have a binary showing the problem. > > Which version of valgrind are you using? > > Josef > > > I have > > been able to cross reference a few of the hex numbers to symbols in the > > file. For example: > > > > 0x0804F304 -> main > > 0x0804F76C -> _ZN6TreffyC1Ev > > 0x0804FA84 -> _ZV6Treffy4TestEv > > > > These correspond to the functions main, Treffy constructor, and > > Treffy::Test. So it seems that there is some name mangling. Does this > > help to shed light on the problem? > > > > Thanks for the help... > > > > Justace > > > > On Tue, 2005-07-12 at 11:54 +0200, Josef Weidendorfer wrote: > > > Hi, > > > > > > On Tuesday 12 July 2005 00:09, Justace Clutter wrote: > > > > Valgrinders... > > > > > > > > I was working on a program and then decided to look into using > > > > kcachegrind to help me profile and generate call graphs. When running > > > > I noticed that there was a bunch of numbers where I thought there > > > > should have been function or method names. I looked everywhere I could > > > > and can not find a way to fix the problem. So, I wrote a very small > > > > and silly program to see if that would fix it, nope, same problem. I am > > > > using gcc 3.4.4 on Gentoo and using the "-ggdb" flag only for my > > > > compiles and links. > > > > > > Sorry, I just can not see your problem in the small test you provided. > > > The only thing I see is that system libraries on your system are > > > stripped. If you look only at the symbols from your binary (Grouping by > > > ELF object, select "test"), almost all entries in the list have function > > > names and are not hex numbers. So your compiler is producing the debug > > > info, and valgrind is loading this info. The entries without names are > > > compiler generated without symbol info. > > > > > > Regarding the screen shot, it actually looks like there are quite a few > > > functions without symbol info. Either the compiler does not provide debug > > > info (seems unlikely), the binary is somehow stripped afterwards (you > > > should recheck with "nm" if expected symbols are actually provided in the > > > binary), or the valgrind debug info reader is buggy. > > > > > > Unfortunately I can not reproduce the problem, and as said above, the > > > small test code seems fine. Can you give me a hex number there where a > > > symbol name (from the "test" binary) should show up? Or generate a test > > > case where you can show this? > > > > > > Josef > > > > > > > I also tried a variety of combinations between -p, -pg, -g, > > > > -g3... I am including in this email a tarball of the test code to show > > > > what I mean along with with a picture of the desktop showing the > > > > offending program. I am really not sure where to go with this. The > > > > tools will be un-usable if I can not tell which functions are which. > > > > Thanks in advance for any help that you can provide. > > > > > > > > Justace clutter > > > > > > > > The attachements were too big so I posted them to a web address. > > > > > > > > http://clued0.fnal.gov/~prophecy/valgrind > > > > > > > > P.S. Sorry for the repost > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > This SF.Net email is sponsored by the 'Do More With Dual!' webinar > > > > happening July 14 at 8am PDT/11am EDT. We invite you to explore the > > > > latest in dual core and dual graphics technology at this free one hour > > > > event hosted by HP, AMD, and NVIDIA. To register visit > > > > http://www.hp.com/go/dualwebinar > > > > _______________________________________________ > > > > Valgrind-users mailing list > > > > Val...@li... > > > > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Josef W. <Jos...@gm...> - 2005-07-12 18:07:00
|
Hi, On Tuesday 12 July 2005 11:52, Justace Clutter wrote: > Just as a side note I also decided to post the binary file treffytng at > the same location. If I start valgrind with your binary, the debug reader reads the symbols of the binary itself quite fine (both 2.4.0 und 3.0.0.SVN). It is strange that in your "valgrind_output" file, the debug reader never reads in symbols from "treffytng" at all. Can you run it again with "-v", i.e. valgrind -v --tool=none --trace-symtab=yes <yourprogram> Josef |
|
From: Justace C. <pro...@co...> - 2005-07-12 18:29:15
|
Could this be a problem of how our valgrinds are compiled? Or the version of GCC on our computers. I am using 3.4.4 which from what I understand is a relatively new version. Justace On Tue, 2005-07-12 at 19:37 +0200, Josef Weidendorfer wrote: > Hi, > > On Tuesday 12 July 2005 11:52, Justace Clutter wrote: > > Just as a side note I also decided to post the binary file treffytng at > > the same location. > > If I start valgrind with your binary, the debug reader reads the symbols of > the binary itself quite fine (both 2.4.0 und 3.0.0.SVN). > It is strange that in your "valgrind_output" file, the debug reader never > reads in symbols from "treffytng" at all. Can you run it again with "-v", > i.e. > valgrind -v --tool=none --trace-symtab=yes <yourprogram> > > Josef > > > ------------------------------------------------------- > This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening > July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual > core and dual graphics technology at this free one hour event hosted by HP, > AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Josef W. <Jos...@gm...> - 2005-07-12 19:44:15
|
Hi Justace, I really do not know why valgrind does not read in debug info from treffytng on your system. On mine this is working. I am simply missing a line saying ==6874== Reading syms from /home/weidendo/tmp/vgbug/treffytng (0x8048000) in valgrinds output (because of verbose "-v"). What happens if you start the binary via absolute path, e.g. valgrind -v --tool=none /path/treffytng You could also check with strace -eopen valgrind treffytng if there is any suspicious line failing to open the binary for debug reading. Someone other on the list has any idea? On Tuesday 12 July 2005 15:29, you wrote: > Could this be a problem of how our valgrinds are compiled? Did you compile valgrind in any special way? > Or the version of GCC on our computers. I am using 3.4.4 which from > what I understand is a relatively new version. Your binary seems running quite fine with my valgrind installation, so the compiler does not seem to be the problem. It must have to do something with the setup of your computer, but I have no idea, sorry. Josef |
|
From: Justace C. <pro...@co...> - 2005-07-12 20:19:27
|
Well, I have some news! First off I would like to thank Mr. Weidendorfer for all the help. I have found, through his suggestion that running a program with a space in the path causes these problems. The program was originally in /home/prophecy/Desktop/Summer Project/treffytng/src/treffytng I moved it to and recompiled it to /home/prophecy/Desktop/treffytng and it works great. So I guess this should be a charge to double check how things handle full paths with respect to spaces. Again, thanks for all the help. Justace On Tue, 2005-07-12 at 21:41 +0200, Josef Weidendorfer wrote: > valgrind -v --tool=none /path/treffytng |
|
From: Nicholas N. <nj...@cs...> - 2005-07-12 20:34:08
|
On Tue, 12 Jul 2005, Justace Clutter wrote: > I have some news! First off I would like to thank Mr. Weidendorfer for > all the help. I have found, through his suggestion that running a > program with a space in the path causes these problems. The program was > originally in > > /home/prophecy/Desktop/Summer Project/treffytng/src/treffytng > > I moved it to and recompiled it to > > /home/prophecy/Desktop/treffytng > > and it works great. Ah... this is bug #88678 (http://bugs.kde.org/show_bug.cgi?id=88678). N |
|
From: Nicholas N. <nj...@cs...> - 2005-07-20 15:05:51
|
On Tue, 12 Jul 2005, Nicholas Nethercote wrote: >> I have some news! First off I would like to thank Mr. Weidendorfer >> for >> all the help. I have found, through his suggestion that running a >> program with a space in the path causes these problems. The program was >> originally in >> >> /home/prophecy/Desktop/Summer Project/treffytng/src/treffytng >> >> I moved it to and recompiled it to >> >> /home/prophecy/Desktop/treffytng >> >> and it works great. > > Ah... this is bug #88678 (http://bugs.kde.org/show_bug.cgi?id=88678). I fixed this a few days ago. The fix will be present in 3.0.0 when it is released. N |
|
From: Justace C. <pro...@co...> - 2005-07-12 18:26:55
|
Ok that output is now at http://clued0.fnal.gov/~prophecy/valgrind/valgrind_output_2 Justace On Tue, 2005-07-12 at 19:37 +0200, Josef Weidendorfer wrote: > Hi, > > On Tuesday 12 July 2005 11:52, Justace Clutter wrote: > > Just as a side note I also decided to post the binary file treffytng at > > the same location. > > If I start valgrind with your binary, the debug reader reads the symbols of > the binary itself quite fine (both 2.4.0 und 3.0.0.SVN). > It is strange that in your "valgrind_output" file, the debug reader never > reads in symbols from "treffytng" at all. Can you run it again with "-v", > i.e. > valgrind -v --tool=none --trace-symtab=yes <yourprogram> > > Josef |