You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
1
(3) |
2
(1) |
|
3
(3) |
4
(6) |
5
(6) |
6
(9) |
7
(11) |
8
(8) |
9
(1) |
|
10
(4) |
11
(4) |
12
(13) |
13
(21) |
14
(5) |
15
(4) |
16
(6) |
|
17
(4) |
18
(12) |
19
(3) |
20
(20) |
21
(8) |
22
(4) |
23
(1) |
|
24
(1) |
25
(8) |
26
(11) |
27
(3) |
28
(8) |
29
(1) |
30
(3) |
|
From: <joh...@gm...> - 2006-09-13 13:40:15
|
Hi Tom, $ apt-cache policy binutils binutils: Installed: 2.17-1ubuntu1 $ gcc --version gcc (GCC) 4.1.2 20060903 (prerelease) (Ubuntu 4.1.1-13ubuntu1) But i also have gcc 4.0 and gcc 3.4 installed. cmake should be using the 4.1.2 version right? I'm not sure how to check sorry. John On 13/09/06, Tom Hughes <to...@co...> wrote: > In message <200...@ac...> > Julian Seward <js...@ac...> wrote: > > > Using the libQtGui.so.4.2.0 you sent, I can reproduce the failure using > > 3.2.0. Whereas the upcoming 3.2.1 does not crash, which is good. > > > > I'm more concerned about zillions of these > > --3382-- DWARF2 CFI reader: unhandled CFI instruction 0:24 > > > > The DWARF3 Draft 8 spec doesn't what instruction number 24 is, > > only 0 through 23. Tom, any ideas? > > Not really... The final version of DWARF3 is out now (get it from > dwarf.freestandards.org) and that only seems to define 0 to 22. > > I guess the next question is, what versions of gcc and binutils were > used to build that library? > > Tom > > -- > Tom Hughes (to...@co...) > http://www.compton.nu/ > > ------------------------------------------------------------------------- > 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 > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Tom H. <to...@co...> - 2006-09-13 13:05:31
|
In message <C01...@ai...>
Jeff Harris <Je...@ai...> wrote:
> Would it be acceptable to have Valgrind keep track of all of the mmap'd
> segments? It may be wasteful because there shouldn't ever be code in
> the writable data segments, but it should work, right?
We do keep track of all mmap'd segments, but we only try and load
symbols from ones which we think contain code.
You can easily alter that routine to consider writable segments - it
will still look for an ELF header before doing anything to verify that
it is code anyway.
This was in fact done previously for the wine patches as wine liked
to map code in writable segments at the time.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Harris, J. <Je...@ai...> - 2006-09-13 13:02:14
|
I will try to reproduce the callgraph issues with a smaller example if I have time between other projects. I don't think the compiler is producing invalid symbol names. GDB and glibc backtrace functions work just fine with determining the correct symbols. Jeff -----Original Message----- From: Josef Weidendorfer [mailto:Jos...@gm...]=20 Sent: Tuesday, September 12, 2006 6:24 PM To: val...@li... Cc: Harris, Jeff Subject: Re: [Valgrind-users] Callgrind results on ppc Hi, On Tuesday 12 September 2006 15:41, Harris, Jeff wrote: > Also on the PPC run I get cycles detected See below. > in some of the dynamic loader=20 > function calls, like dl_main. The cycles do not appear on the x86 run. > I have attached the output from Valgrind for both the ppc and x86 runs. >=20 > In profiling our real application on ppc, the output in kcachegrind > seems to be getting the wrong symbols in some cases. Hmm... either there is some bug in Valgrind (wrong interpretation of symbol information on PPC?), or the compiler does not produce correct data (e.g. wrong "length" of symbols?). If some code gets the wrong function name attributed, it easily can be that KCachegrind detects some bogus cycles.=20 In general some warning about callgrind on PPC32/64. Obviously, it is reasonable stable, but I never had time to fully check whether call graph tracing on PPC produces senseable call graphs in all cases. At least, one problem is known to not be handled correctly: On PPC, jumps are used for both calls and returns. So theoretically, there are conditional calls and returns on PPC. This is not possible on x86, and currently _not_ handled in callgrind. However, conditional calls/returns seem to be used only in rare cases (?). Josef |
|
From: Harris, J. <Je...@ai...> - 2006-09-13 12:59:05
|
Would it be acceptable to have Valgrind keep track of all of the mmap'd segments? It may be wasteful because there shouldn't ever be code in the writable data segments, but it should work, right? We probably will upgrade to a newer gcc at some point. Currently we're at gcc 3.2.3. Now I have another reason to push for an upgrade because likely the kernel will not be able to share the code segments between processes as they are writable. For libstdc++, that's a sizeable amount of memory we can reclaim. Until then, I can profile a fair amount on our x86 platform. =20 Jeff -----Original Message----- From: Julian Seward [mailto:js...@ac...]=20 Sent: Tuesday, September 12, 2006 5:56 PM To: val...@li... Cc: Harris, Jeff Subject: Re: [Valgrind-users] Callgrind results on ppc Wow. You are certainly a determined investigator .. That sounds like a plausible scenario to me. I remember having a bunch of trouble with that particular logic (in VG_(di_notify_mmap)) at some point in the ppc32-linux integration, and I believe I left some comments in there. > Newer versions of gcc do not seem to have this issue, from looking at Wouldn't it be simpler for you to use a newer gcc, then? libstdc++ is tied to gcc, so upgrading gcc would fix it? Out of interest, what version of gcc is this? I know that 3.3.3 works ok on ppc32 and ppc64; one of the dev machines we used for ppc used gcc 3.3.3. J |
|
From: Tom H. <to...@co...> - 2006-09-13 12:35:51
|
In message <115...@sp...>
Dennis Lubert <pla...@pr...> wrote:
> Am Mittwoch, den 13.09.2006, 10:13 +0100 schrieb Tom Hughes:
>
>> On recent linux systems fork is actually done with clone so you do
>> have the situation I described.
>>
>> Unfortunately --trace-children is not going to help you.
>>
>> The problem is that valgrind can't really untangle itself from an
>> existing process, so it is only on an exec (when the process image
>> in memory is completely replace) that we can remove ourselves.
>
> Can't V fork() itself and then exec the program that its running? Or
> something like that?
If the client program didn't mind losing all the state it had in
memory then yes, it could. I rather suspect it will mind though.
Don't forget that a fork creates an exact clone of the process at
that point in time, complete with any data structures it has built
in dynamically allocated memory, any file descriptors it has open
and so on.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Dennis L. <pla...@pr...> - 2006-09-13 12:17:25
|
Am Mittwoch, den 13.09.2006, 10:13 +0100 schrieb Tom Hughes: > > On recent linux systems fork is actually done with clone so you do > have the situation I described. > > Unfortunately --trace-children is not going to help you. > > The problem is that valgrind can't really untangle itself from an > existing process, so it is only on an exec (when the process image > in memory is completely replace) that we can remove ourselves. Can't V fork() itself and then exec the program that its running? Or something like that? greets Dennis |
|
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 |
|
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: 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: Tom H. <to...@co...> - 2006-09-13 10:59:21
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> Using the libQtGui.so.4.2.0 you sent, I can reproduce the failure using
> 3.2.0. Whereas the upcoming 3.2.1 does not crash, which is good.
>
> I'm more concerned about zillions of these
> --3382-- DWARF2 CFI reader: unhandled CFI instruction 0:24
>
> The DWARF3 Draft 8 spec doesn't what instruction number 24 is,
> only 0 through 23. Tom, any ideas?
Not really... The final version of DWARF3 is out now (get it from
dwarf.freestandards.org) and that only seems to define 0 to 22.
I guess the next question is, what versions of gcc and binutils were
used to build that library?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2006-09-13 10:46:42
|
Using the libQtGui.so.4.2.0 you sent, I can reproduce the failure using 3.2.0. Whereas the upcoming 3.2.1 does not crash, which is good. I'm more concerned about zillions of these --3382-- DWARF2 CFI reader: unhandled CFI instruction 0:24 The DWARF3 Draft 8 spec doesn't what instruction number 24 is, only 0 through 23. Tom, any ideas? J On Wednesday 13 September 2006 01:19, you wrote: > Thank you for helping me! > > I just want to mention that I can run the QT4 demo with no problems, > and that I have rebuilt from scratch qt4 twice with no change. None > of the kde4 programs worked. > > John > > On 13/09/06, Julian Seward <js...@ac...> wrote: > > Ok, it bombed reading info from > > /home/kdedev/src/kde/build/qt-copy/lib/libQtGui.so.4.2.0 > > > > So can you send me that file? > > > > J > > > > On Tuesday 12 September 2006 18:56, joh...@gm... wrote: > > > Hi Julian, > > > > > > Thanks for responding so quickly. I've tried to answer the questions: > > > > What version of Valgrind is this? > > > > > > $ valgrind --version > > > valgrind-3.2.0-Debian > > > > > > > I assume you are running an AMD64 machine. What OS and version is > > > > it? > > > > > > kubuntu, edgy (which is the newest unstable) > > > It is the x86_64 version indeed, so 64bit version of everything > > > > > > > What version of gcc/g++ are you using? > > > > > > $ gcc --version > > > gcc (GCC) 4.1.2 20060903 (prerelease) (Ubuntu 4.1.1-13ubuntu1) > > > > > > > What gcc flags did you build KDE with? > > > > > > I don't know how to check this.. I use cmake sorry. My configure flags > > > are: > > > > > > configure-flags --enable-sendfile --enable-mitshm > > > > > > > Valgrind has asserted whilst reading debugging info from one of the > > > > shared objects making up your KDE build. It would be helpful if you > > > > could re-run Valgrind on your app, but with the additional flag "-v", > > > > and then send the entire log of what it prints out. > > > > > > Okay but I've had to zip it. It's 190KB even zipped so I hope I don't > > > annoy everyone. > > > > > > John |
|
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: Tom H. <to...@co...> - 2006-09-13 09:13:50
|
In message <200...@or...>
Christoph Bartoschek <bar...@or...> wrote:
> I do not have the source of the program, but with strace I see that the new
> child is created with clone:
>
> clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
> child_tidptr=0x2aaaaada62d0) = 20888
>
> And then no execve is performed because the functionality of the child is in
> the same programimage.
On recent linux systems fork is actually done with clone so you do
have the situation I described.
Unfortunately --trace-children is not going to help you.
The problem is that valgrind can't really untangle itself from an
existing process, so it is only on an exec (when the process image
in memory is completely replace) that we can remove ourselves.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Christoph B. <bar...@or...> - 2006-09-13 09:01:32
|
Am Mittwoch, 13. September 2006 10:40 schrieb Tom Hughes: > In message <200...@or...> > > Christoph Bartoschek <bar...@or...> wrote: > > I start our program with the option --trace-children=no but callgrind > > still seems to profile the child our program starts. > > Are you actually doing an exec(), or just a fork()? > > You see trace-children is a bit badly named as it doesn't control > tracing over fork but tracing over exec, so if you fork but don't > actually exec a new program it will still be traced. > > Tom I do not have the source of the program, but with strace I see that the new child is created with clone: clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x2aaaaada62d0) = 20888 And then no execve is performed because the functionality of the child is in the same programimage. Christoph |
|
From: Tom H. <to...@co...> - 2006-09-13 08:40:14
|
In message <200...@or...>
Christoph Bartoschek <bar...@or...> wrote:
> I start our program with the option --trace-children=no but callgrind still
> seems to profile the child our program starts.
Are you actually doing an exec(), or just a fork()?
You see trace-children is a bit badly named as it doesn't control
tracing over fork but tracing over exec, so if you fork but don't
actually exec a new program it will still be traced.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Christoph B. <bar...@or...> - 2006-09-13 08:36:24
|
Hi, I start our program with the option --trace-children=no but callgrind still seems to profile the child our program starts. In the directory I see one logfile for the main programm vg.19970 and two callgrind logfiles (callgrind.out.19970 and callgrind.out.19972). How to prevent the behaviour? Christoph |
|
From: Christoph B. <bar...@or...> - 2006-09-13 08:19:41
|
Hi, with the recent fixes I am able to profile the part of the code that is interessting for me. But there is one problem left. Sometimes after starting instrumentation it switches itself off again. And I have to restart it. Given this I cannot be sure that instrumentation is always done and that I do not forget to switch it on again. Here is a log of a sample session: -bash-3.00$ callgrind_control -i on 19970 PID 19970: program [requesting '+Instrumentation'...] OK. -bash-3.00$ callgrind_control -s 19970 PID 19970: program [requesting 'Status'...] Number of threads: 1 Events collected: Ir Dr Dw I1mr D1mr D1mw I2mr D2mr D2mw Functions: 1,636 (executed 257,435, contexts 1,636) Basic blocks: 3,894 (executed 4,762,919, call sites 2,233) -bash-3.00$ callgrind_control -s 19970 PID 19970: program [requesting 'Status'...] No information available as instrumentation is switched off. -bash-3.00$ callgrind_control -i on 19970 PID 19970: program [requesting '+Instrumentation'...] OK. -bash-3.00$ callgrind_control -s 19970 PID 19970: program [requesting 'Status'...] Number of threads: 0 Events collected: Ir Dr Dw I1mr D1mr D1mw I2mr D2mr D2mw Functions: 563 (executed 141,123, contexts 563) Basic blocks: 3,464 (executed 983,886, call sites 2,050) -bash-3.00$ callgrind_control -s 19970 PID 19970: program [requesting 'Status'...] Number of threads: 0 Events collected: Ir Dr Dw I1mr D1mr D1mw I2mr D2mr D2mw Functions: 1,181 (executed 2,334,797, contexts 1,181) Basic blocks: 8,057 (executed 16,365,930, call sites 4,962) Christoph |
|
From: Mohit T. <moh...@gm...> - 2006-09-13 03:01:21
|
Hello, I have just begun to use Valgrind, and am building a simple tool to quantify the performance hit on the target application on the increasing the amount of instrumentation. I read that Valgrind allocates 256MB in the higher part of the virtual address space for itself and its tools. I was wondering if the memory once allocated remains fixed? Or can Valgrind also move the memory allocated to a tool to a different virtual address, in some circumstance? Thanks a lot, Mohit |
|
From: Julian S. <js...@ac...> - 2006-09-12 23:30:00
|
Ok, it bombed reading info from /home/kdedev/src/kde/build/qt-copy/lib/libQtGui.so.4.2.0 So can you send me that file? J On Tuesday 12 September 2006 18:56, joh...@gm... wrote: > Hi Julian, > > Thanks for responding so quickly. I've tried to answer the questions: > > What version of Valgrind is this? > > $ valgrind --version > valgrind-3.2.0-Debian > > > I assume you are running an AMD64 machine. What OS and version is it? > > kubuntu, edgy (which is the newest unstable) > It is the x86_64 version indeed, so 64bit version of everything > > > What version of gcc/g++ are you using? > > $ gcc --version > gcc (GCC) 4.1.2 20060903 (prerelease) (Ubuntu 4.1.1-13ubuntu1) > > > What gcc flags did you build KDE with? > > I don't know how to check this.. I use cmake sorry. My configure flags > are: > > configure-flags --enable-sendfile --enable-mitshm > > > Valgrind has asserted whilst reading debugging info from one of the > > shared objects making up your KDE build. It would be helpful if you > > could re-run Valgrind on your app, but with the additional flag "-v", > > and then send the entire log of what it prints out. > > Okay but I've had to zip it. It's 190KB even zipped so I hope I don't > annoy everyone. > > John |
|
From: Josef W. <Jos...@gm...> - 2006-09-12 22:24:16
|
Hi, On Tuesday 12 September 2006 15:41, Harris, Jeff wrote: > Also on the PPC run I get cycles detected See below. > in some of the dynamic loader > function calls, like dl_main. The cycles do not appear on the x86 run. > I have attached the output from Valgrind for both the ppc and x86 runs. > > In profiling our real application on ppc, the output in kcachegrind > seems to be getting the wrong symbols in some cases. Hmm... either there is some bug in Valgrind (wrong interpretation of symbol information on PPC?), or the compiler does not produce correct data (e.g. wrong "length" of symbols?). If some code gets the wrong function name attributed, it easily can be that KCachegrind detects some bogus cycles. In general some warning about callgrind on PPC32/64. Obviously, it is reasonable stable, but I never had time to fully check whether call graph tracing on PPC produces senseable call graphs in all cases. At least, one problem is known to not be handled correctly: On PPC, jumps are used for both calls and returns. So theoretically, there are conditional calls and returns on PPC. This is not possible on x86, and currently _not_ handled in callgrind. However, conditional calls/returns seem to be used only in rare cases (?). Josef |
|
From: Julian S. <js...@ac...> - 2006-09-12 21:56:13
|
Wow. You are certainly a determined investigator .. That sounds like a plausible scenario to me. I remember having a bunch of trouble with that particular logic (in VG_(di_notify_mmap)) at some point in the ppc32-linux integration, and I believe I left some comments in there. > Newer versions of gcc do not seem to have this issue, from looking at Wouldn't it be simpler for you to use a newer gcc, then? libstdc++ is tied to gcc, so upgrading gcc would fix it? Out of interest, what version of gcc is this? I know that 3.3.3 works ok on ppc32 and ppc64; one of the dev machines we used for ppc used gcc 3.3.3. J |
|
From: Harris, J. <Je...@ai...> - 2006-09-12 21:44:14
|
After much investigation into Valgrind, libstdc++, and gcc, I think I've
figured out why that library behaves differently. The issue is that the
normally read-only text and data section in the library is being flagged
as writable by the linker. There is a test in the VG_(di_notify_mmap)
function for whether a particular mmap is for a "code" segment that
Valgrind will want record. For PPC, it's looking for a segment that is
readable and executable, but not writable. Such a section will not
exist in the libstdc++ library.
On x86, the library's read-only sections are indeed read-only. On PPC,
however, there are some symbols in the .rodata section which are marked
as writable, causing the linker to mark all of the read-only sections as
writable. The culprit are C++ type_info RTTI symbols. GCC is
generating them as writable symbols in the .rodata section. There is
PPC specific code for determining the section for a particular symbol.
There appears to be a bug where the symbol should probably be writable
since it's relocatable, but the symbol is placed in a read-only section.
There doesn't appear to be a straight-forward patch to fix it, so I'm in
for more work.
Newer versions of gcc do not seem to have this issue, from looking at
the code. The PPC specific hooks have been rewritten to use the common
code. It would be nice if Valgrind could recognize the writable
sections, but I can understand that my situation is certainly not
"normal".
Jeff
-----Original Message-----
From: val...@li...
[mailto:val...@li...] On Behalf Of Tom
Hughes
Sent: Tuesday, September 12, 2006 11:35 AM
To: val...@li...
Subject: Re: [Valgrind-users] Callgrind results on ppc
In message
<C01...@ai...>
Jeff Harris <Je...@ai...> wrote:
> Both environments are using dynamic libstdc++:
>
>> powerpc-ai-linux-ldd a.out
> libstdc++.so.5 =3D> libstdc++.so.5 (0x0)
> libm.so.6 =3D> libm.so.6 (0x0)
> libgcc_s.so.1 =3D> libgcc_s.so.1 (0x0)
> libc.so.6 =3D> libc.so.6 (0x0)
> /lib/ld.so.1 =3D> /lib/ld.so.1 (0x0)
>
> The addresses are zero because I'm using the cross-compiler ldd on my
> PC. The x86 version is the same. All of the symbols are missing.
The
> library on both platform is stripped, but still has its dynamic
> relocation entries. The libc and libm libraries are also stripped,
but
> still load with Valgrind.
I was going on the fact that the x86 output contains this:
--11147-- Reading syms from /lib/libstdc++.so.5.0.3 (0x401A000)
while the PPC output does not contain an equivalent line.
That line will appear regardless of whether or not it actually finds
any symbols - all that has to happen for that to appear is that
valgrind has to see an mmap that appears to be mapping in a given
shared library.
If it is dynamically linked then either the dynamic linker has not
loaded it for some reason or VG_(di_notify_mmap) has not recognised
the mapping as being from a library.
You might want to try adding --trace-syscalls=3Dyes and look for
evidence of it opening libstdc++ and mapping from it. If you find
that it is doing so that I would try adding some extra trace
statements to VG_(di_notify_mmap) in coregrind/m_debuginfo/debuginfo.c
to try and work out why valgrind is not spotting it.
Tom
--=20
Tom Hughes (to...@co...)
http://www.compton.nu/
------------------------------------------------------------------------
-
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
easier
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=3D=
121642
_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: Julian S. <js...@ac...> - 2006-09-12 20:56:03
|
Hi Josef,
That's great - it does seem to fix it, at least on amd64. Did not
test on x86. I'll push it into 3.2.1.
J
On Tuesday 12 September 2006 20:03, Josef Weidendorfer wrote:
> Hi Christoph, hi Julian,
>
> I just got internet connection again...
> Thanks for the detailed analysis.
>
> The "BB with 0 instructions" is easy to explain, and the bug easy to
> fix. It happens when you switch to full instrumentation (and callgrinds
> call graph tracing) in the middle of a run: Whenever the shadow callstack
> is empty, but callgrind sees a return instruction (ie. a shadow callstack
> underrun), it creates an artifical BB which is faked to have called
> the function we are returning from. This way, the call arc is noted and
> will be in the profile data.
>
> This bug seems to be in callgrind from the beginning, as old VGs more
> or less also started in the middle of a run (when the VG shared lib
> got control).
>
> So
>
> > + { tl_assert(bb->instr_count > 0);
>
> is not correct.
> Better do
>
> ======================================================================
> --- global.h (Revision 6044)
> +++ global.h (Arbeitskopie)
> @@ -688,7 +688,8 @@
> static __inline__ Addr bb_addr(BB* bb)
> { return bb->offset + bb->obj->offset; }
> static __inline__ Addr bb_jmpaddr(BB* bb)
> - { return bb->instr[bb->instr_count-1].instr_offset + bb->offset +
> bb->obj->offset; } + { UInt off = (bb->instr_count > 0) ?
> bb->instr[bb->instr_count-1].instr_offset : 0; + return off + bb->offset
> + bb->obj->offset; }
>
> /* from fn.c */
> void CLG_(init_fn_array)(fn_array*);
> ======================================================================
>
>
> Josef
>
> -------------------------------------------------------------------------
> 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
> easier Download IBM WebSphere Application Server v.1.0.1 based on Apache
> Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: Josef W. <Jos...@gm...> - 2006-09-12 19:03:58
|
Hi Christoph, hi Julian,
I just got internet connection again...
Thanks for the detailed analysis.
The "BB with 0 instructions" is easy to explain, and the bug easy to
fix. It happens when you switch to full instrumentation (and callgrinds
call graph tracing) in the middle of a run: Whenever the shadow callstack
is empty, but callgrind sees a return instruction (ie. a shadow callstack
underrun), it creates an artifical BB which is faked to have called
the function we are returning from. This way, the call arc is noted and
will be in the profile data.
This bug seems to be in callgrind from the beginning, as old VGs more
or less also started in the middle of a run (when the VG shared lib
got control).
So
> + { tl_assert(bb->instr_count > 0);
is not correct.
Better do
======================================================================
--- global.h (Revision 6044)
+++ global.h (Arbeitskopie)
@@ -688,7 +688,8 @@
static __inline__ Addr bb_addr(BB* bb)
{ return bb->offset + bb->obj->offset; }
static __inline__ Addr bb_jmpaddr(BB* bb)
- { return bb->instr[bb->instr_count-1].instr_offset + bb->offset + bb->obj->offset; }
+ { UInt off = (bb->instr_count > 0) ? bb->instr[bb->instr_count-1].instr_offset : 0;
+ return off + bb->offset + bb->obj->offset; }
/* from fn.c */
void CLG_(init_fn_array)(fn_array*);
======================================================================
Josef
|
|
From: Julian S. <js...@ac...> - 2006-09-12 15:44:50
|
> You might want to try adding --trace-syscalls=yes and look for > evidence of it opening libstdc++ and mapping from it. If you find > that it is doing so that I would try adding some extra trace > statements to VG_(di_notify_mmap) in coregrind/m_debuginfo/debuginfo.c > to try and work out why valgrind is not spotting it. Also you could try running with --trace-symtab=yes to see gigabytes of gruesome crud showing what the debuginfo reader is doing, in great detail. J |