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
|
4
(8) |
5
(4) |
6
(11) |
7
(9) |
8
(5) |
9
|
|
10
(4) |
11
(5) |
12
(1) |
13
(4) |
14
(4) |
15
(1) |
16
|
|
17
|
18
|
19
(3) |
20
(8) |
21
(7) |
22
|
23
|
|
24
(5) |
25
(14) |
26
(8) |
27
(18) |
28
(11) |
29
(15) |
|
|
From: Josef W. <Jos...@gm...> - 2008-02-11 18:06:00
|
On Monday 11 February 2008, Salvatore Iovene wrote: > On Mon, Feb 11, 2008 at 05:27:45PM +0100, =?ISO-8859-1?Q?S=E9bastien_Sabl=E9_ wrote: > > Just compile valgrind with --enable-python then > > valgrind --tool=callgrind --python-mode python foo.py > > Hi all, > I'm jumping in this thread because I have question which is probably > related. I work on some C/C++ libraries, that are tested with a C > tester program. This tester program, then, is run several times in a > python script (I need python to control several instances of this > program, that interact with each other). > > Nowadays, I'm profiling all this by having python call the tester > program within valgrind (memcheck), and then manually inspecting the > logs. > > Since I run this python test suite from the cmake/ctest suite, and > would like the profiling results to end up in the Dart dashboard, I > would need to actually valgrind python and catch the memory leaks of > the processes that python spawns. But unfortunately valgrind doesn't > seem to catch those, I end up with no leaks (even if there are some). > > What is this python-mode? Can it be useful in my use case? This thread is about profiling C code which is linked into python, and not about profiling processes spawn by python. So I do not think this is relevant to your use case. Josef > Thanks a lot in advance! > |
|
From: Josef W. <Jos...@gm...> - 2008-02-11 18:01:40
|
Hi Sébastien, On Monday 11 February 2008, Sébastien Sablé wrote: > I have been able to push Python calls on the stack according to what you > explained and I can now correctly see them with Kcachegrind, which makes > profiling my application much easier. Cool. > I added a --python-mode option to callgrind, which will activate the > detection of PyEval_EvalFrameEx and use this function to get the python > context. > > The reason why I prefer to use callgrind instead of > hotshot/cProfile/profile is that my application mixes C and Python > (about 30% python, 15% C generated by Pyrex and 55% legacy C); so > hotshot gives me some very superficial results. Ah, I did not think about this use case of mixing C/Python. Good that this matches your requirements! The question now is if there is a possibility to integrate this with callgrind somehow. I understand that quite some people could find this useful. But to be true, the current solution looks quite "hacky" to me. To use it, one has to modify things in the python interpreter, and there is this special case for python in callgrind. Up to now, callgrind is independent from the language used, as long as there exists debug information for the binary. So, one way would be to add the patch as user contribution into a contrib/ directory. And if there is enough pressure for a distribution, it could provide the patched callgrind. Or I try to refactor most parts of callgrind to make it available as modules for other tools. And callgrind itself would shrink dramatically in code size. Not really realistic. Another way would be to try to achieve the same/similar result with a more general solution not specific for python, but for any type of interpreter. E.g. using client requests, which allow to specify function calls/returns happening in a high-level call-graph. I suppose that your PyEval_EvalFrameEx function would be the ideal place to notify callgrind about these events. Hmm... this would add another dimension to the code position such as (high-level function, low-level function), and thus to some "explosion" of positions. In fact, it is quite similar to another dimension I wanted to add since quite some time: accessed data. I just wonder if there is an easy extension of the format and visualization, or if it is not really worth it... Josef |
|
From: Sébastien S. <sa...@us...> - 2008-02-11 16:28:42
|
Hi Josef,
Thanks a lot for those explanations! It was exactly what I needed.
I have been able to push Python calls on the stack according to what you
explained and I can now correctly see them with Kcachegrind, which makes
profiling my application much easier.
I added a --python-mode option to callgrind, which will activate the
detection of PyEval_EvalFrameEx and use this function to get the python
context.
The reason why I prefer to use callgrind instead of
hotshot/cProfile/profile is that my application mixes C and Python
(about 30% python, 15% C generated by Pyrex and 55% legacy C); so
hotshot gives me some very superficial results.
I am interested by the time spent in the python runtime, but I need to
know to which python code it corresponds in order to be able to reduce
this time.
I also found that since hotshot is using timestamps rather than
instruction counts like callgrind, the result is much less reliable
(especially when profiling very fast loops as the time spent collecting
profiling data can generate a shift).
I attach a first patch. It needs a few changes as I would like to pass
get_fn_node_inseg a valid obj_node, so that I can more easily
distinguish python modules in Kcachegrind. But it works well as is.
Just compile valgrind with --enable-python then
valgrind --tool=callgrind --python-mode python foo.py
regards
--
Sébastien Sablé
Josef Weidendorfer a écrit :
> On Friday 08 February 2008, Sébastien Sablé wrote:
>> When running callgrind on such an application, I can clearly see the C
>> calls of the application but all the python part is represented by a
>> complex tree of Py* functions representing Python C internals.
>>
>> Using callgrind --fn-skip='Py*' option makes it possible to ignore most
>> of Python internals but then a lot of information is missing.
>>
>> So I would like to extend callgrind so that it can handle Python calls.
>
> Interesting.
> Why do you not use the profiler built into python itself, for example
> hotshot? There is a converter provided with the KCachegrind package.
>
> On the other hand, if you are interested in cache misses and number of
> instructions executed, your approach is reasonable. However, I am not
> really sure this is the right approach, as the results will depend on the
> implementation of the python interpreter/byte code compiler, and only
> indirectly on your code (hmm.. but so will the real runtime).
>
>> Python gives the possibility to attach a C function to be called each
>> time a python function is called with PyEval_SetTrace. So I made of very
>> simple callgrind_helper module to enable this callback.
>>
>> Then by modifying callgrind/callstack.c:push_call_stack I can get the
>> Python context (file, function and lineno) for which
>> callgrind_helper_callback is called (see provided patch).
>
> Hmm... not really the right place ;-)
>
> First:
> To get a function name into the output, you have to create a fn_node
> struct for it. A factory function for these structs is
> "get_fn_node_inseg( si, filename, fnname)" in callgrind/fn.c
> The first parameter specifies the image (shared lib/binary), a value
> of 0 should be OK here.
>
> Second:
> You have to be aware that there exist actually
> two shadow stacks in callgrind. The one which is modified in
> "callgrind/callstack.c:push_call_stack" is "CLG_(current_call_stack)".
> This one exactly mirrors the real stack and is synchronised via the
> real stack pointer, e.g. to get longjmp's and C++ exception handling right.
>
> The other one ("CLG_(current_fn_stack)"), which differs from the real
> shadow stack, is responsible for separating counter values, and for
> the profile output later on. E.g. by your use of "--fn-skip", you trigger
> changes between the two shadow stacks: some real functions never make it
> onto the second stack, and thus will not appear in the output.
> The second stack is changed e.g. with push_cxt(). The important line
> to change probably is callgrind/bbcc.c:756:
> ...
> CLG_(push_cxt)(CLG_(get_fn_node)(bb));
> ....
>
> Instead of pushing the fn_node struct for the current basic block (bb),
> you could push another fn_node struct onto the second call stack here,
> created dynamically (but please only once for every python function).
> Of course, this should only happen when "bb" maps to your helper callback.
> You should be able to access your python FrameObject via the "sp" pointer.
>
> Hope this helps,
> Josef
>
>
>> Now I need to push these calls into callgrind call stack. I have started
>> to analyze callgrind code to see how this can be done, but I would
>> appreciate some hints from someone familiar with callgrind internals on
>> how this can best be done.
>>
>> Thanks in advance
>>
>> --
>> Sébastien Sablé
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
|
|
From: Julian S. <js...@ac...> - 2008-02-11 00:00:15
|
On Sunday 10 February 2008 23:13, Dan Kegel wrote: > On Feb 10, 2008 1:49 PM, Tom Hughes <to...@co...> wrote: > > I think just about everything in the patch on winehq is in now. The > > last bit was the stack stuff, and I committed that (or rather something > > equivalent, and in fact better) last week. > > Well, bust my buttons. Sure enough, valgrind from svn seems > to work with Wine. Hey, that's great news! J |
|
From: Dan K. <da...@ke...> - 2008-02-10 22:13:53
|
On Feb 10, 2008 1:49 PM, Tom Hughes <to...@co...> wrote: > I think just about everything in the patch on winehq is in now. The > last bit was the stack stuff, and I committed that (or rather something > equivalent, and in fact better) last week. Well, bust my buttons. Sure enough, valgrind from svn seems to work with Wine. I'm even getting good stack traces, which wasn't always happening before, so perhaps your stack stuff is in fact better. I guess I'll start testing it a bit more widely. Thanks! - Dan |
|
From: Tom H. <to...@co...> - 2008-02-10 21:50:03
|
In message <a71...@ma...>
"Dan Kegel" <da...@ke...> wrote:
> On Feb 10, 2008 11:44 AM, Jim Cromie <jim...@gm...> wrote:
>
> > Vojtech Fried wrote:
> >
> > > I have probably found the cause of this problem. I have forgotten that
> > > our valgrind was patched to work better with wine
> > > (http://wiki.winehq.org/Wine_and_Valgrind). After building the original
> > > (not patched) source valgrind works as expected.
> >
> > Please elaborate on this "better with wine"
>
> Visit that web page, it explains.
>
> > if your patch is not too invasive, and GPLable, maybe you and the devs
> > can work thru it, and give everybody the improvements youve attempted
> > with your patch.
>
> It's not his patch. It's a bunch of valgrind changes to be compatible with
> Wine that have been rattling around for a couple years, most recently
> refreshed by John Reiser in December '07, I think John is planning to
> clean them up and try to get them integrated sometime this year.
I think just about everything in the patch on winehq is in now. The
last bit was the stack stuff, and I committed that (or rather something
equivalent, and in fact better) last week.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Dan K. <da...@ke...> - 2008-02-10 19:48:34
|
On Feb 10, 2008 11:44 AM, Jim Cromie <jim...@gm...> wrote: > Vojtech Fried wrote: > > I have probably found the cause of this problem. I have forgotten that our > > valgrind was patched to work better with wine > > (http://wiki.winehq.org/Wine_and_Valgrind). After building the original (not > > patched) source valgrind works as expected. > > Please elaborate on this "better with wine" Visit that web page, it explains. > if your patch is not too invasive, and GPLable, maybe you and the devs > can work thru it, and > give everybody the improvements youve attempted with your patch. It's not his patch. It's a bunch of valgrind changes to be compatible with Wine that have been rattling around for a couple years, most recently refreshed by John Reiser in December '07, I think John is planning to clean them up and try to get them integrated sometime this year. - Dan |
|
From: Jim C. <jim...@gm...> - 2008-02-10 19:45:16
|
Vojtech Fried wrote: > I have probably found the cause of this problem. I have forgotten that our > valgrind was patched to work better with wine > (http://wiki.winehq.org/Wine_and_Valgrind). After building the original (not > patched) source valgrind works as expected. > > Please elaborate on this "better with wine" if your patch is not too invasive, and GPLable, maybe you and the devs can work thru it, and give everybody the improvements youve attempted with your patch. |
|
From: Nicholas N. <nj...@cs...> - 2008-02-08 23:28:49
|
On Fri, 8 Feb 2008, Rajesh_Kumar wrote: > I want to develop a custom memory profiler tool that work with the Valgrind > Core, But whatever STEPS are given in the Valgrind Technical Documentation > for new Tool creation does not work, I am using Red Hat Linux Enterprise > Ed-3, and Valgrind-3.3.0. > > I follow all the steps from 1 to 6 and when I go through the steps 7. > Run > autogen.sh > ./configure --prefix=`pwd`/inst > make install > > something goes wrong, Giving Error such as You must run the autogen.sh at > the top level of gnonlin directory > > Please tell me the right way to Create the new Tool for Valgrind. Please put yourself in our shoes. You haven't given us enough information to answer your question. At the very least, give the specific error message. Nick |
|
From: Josef W. <Jos...@gm...> - 2008-02-08 19:22:17
|
On Friday 08 February 2008, Sébastien Sablé wrote:
> When running callgrind on such an application, I can clearly see the C
> calls of the application but all the python part is represented by a
> complex tree of Py* functions representing Python C internals.
>
> Using callgrind --fn-skip='Py*' option makes it possible to ignore most
> of Python internals but then a lot of information is missing.
>
> So I would like to extend callgrind so that it can handle Python calls.
Interesting.
Why do you not use the profiler built into python itself, for example
hotshot? There is a converter provided with the KCachegrind package.
On the other hand, if you are interested in cache misses and number of
instructions executed, your approach is reasonable. However, I am not
really sure this is the right approach, as the results will depend on the
implementation of the python interpreter/byte code compiler, and only
indirectly on your code (hmm.. but so will the real runtime).
> Python gives the possibility to attach a C function to be called each
> time a python function is called with PyEval_SetTrace. So I made of very
> simple callgrind_helper module to enable this callback.
>
> Then by modifying callgrind/callstack.c:push_call_stack I can get the
> Python context (file, function and lineno) for which
> callgrind_helper_callback is called (see provided patch).
Hmm... not really the right place ;-)
First:
To get a function name into the output, you have to create a fn_node
struct for it. A factory function for these structs is
"get_fn_node_inseg( si, filename, fnname)" in callgrind/fn.c
The first parameter specifies the image (shared lib/binary), a value
of 0 should be OK here.
Second:
You have to be aware that there exist actually
two shadow stacks in callgrind. The one which is modified in
"callgrind/callstack.c:push_call_stack" is "CLG_(current_call_stack)".
This one exactly mirrors the real stack and is synchronised via the
real stack pointer, e.g. to get longjmp's and C++ exception handling right.
The other one ("CLG_(current_fn_stack)"), which differs from the real
shadow stack, is responsible for separating counter values, and for
the profile output later on. E.g. by your use of "--fn-skip", you trigger
changes between the two shadow stacks: some real functions never make it
onto the second stack, and thus will not appear in the output.
The second stack is changed e.g. with push_cxt(). The important line
to change probably is callgrind/bbcc.c:756:
...
CLG_(push_cxt)(CLG_(get_fn_node)(bb));
....
Instead of pushing the fn_node struct for the current basic block (bb),
you could push another fn_node struct onto the second call stack here,
created dynamically (but please only once for every python function).
Of course, this should only happen when "bb" maps to your helper callback.
You should be able to access your python FrameObject via the "sp" pointer.
Hope this helps,
Josef
>
> Now I need to push these calls into callgrind call stack. I have started
> to analyze callgrind code to see how this can be done, but I would
> appreciate some hints from someone familiar with callgrind internals on
> how this can best be done.
>
> Thanks in advance
>
> --
> Sébastien Sablé
>
>
>
>
>
>
>
>
>
|
|
From: Sébastien S. <sa...@us...> - 2008-02-08 18:00:11
|
Hi, I am trying to profile an application which mixes C and Python. When running callgrind on such an application, I can clearly see the C calls of the application but all the python part is represented by a complex tree of Py* functions representing Python C internals. Using callgrind --fn-skip='Py*' option makes it possible to ignore most of Python internals but then a lot of information is missing. So I would like to extend callgrind so that it can handle Python calls. Python gives the possibility to attach a C function to be called each time a python function is called with PyEval_SetTrace. So I made of very simple callgrind_helper module to enable this callback. Then by modifying callgrind/callstack.c:push_call_stack I can get the Python context (file, function and lineno) for which callgrind_helper_callback is called (see provided patch). Now I need to push these calls into callgrind call stack. I have started to analyze callgrind code to see how this can be done, but I would appreciate some hints from someone familiar with callgrind internals on how this can best be done. Thanks in advance -- Sébastien Sablé |
|
From: Rajesh_Kumar <raj...@gm...> - 2008-02-08 08:52:53
|
Hi,
I want to develop a custom memory profiler tool that work with the Valgrind
Core, But whatever STEPS are given in the Valgrind Technical Documentation
for new Tool creation does not work, I am using Red Hat Linux Enterprise
Ed-3, and Valgrind-3.3.0.
I follow all the steps from 1 to 6 and when I go through the steps 7.
Run
autogen.sh
./configure --prefix=`pwd`/inst
make install
something goes wrong, Giving Error such as You must run the autogen.sh at
the top level of gnonlin directory
Please tell me the right way to Create the new Tool for Valgrind.
--
View this message in context: http://www.nabble.com/Valgrind-tool-Creation-tp15351484p15351484.html
Sent from the Valgrind - Users mailing list archive at Nabble.com.
|
|
From: Lieske, R. <Rob...@ca...> - 2008-02-08 07:57:29
|
Hi, >> When helloworld.c is compiled without -fprofile-arcs, the >> valgrind-tools report the correct result of 87.5% (7 of 8 lines). >> The parameter -test-coverage is not related to the problem, it solely >> depends on parameter -fprofile-arcs. > Interesting. VCov is entirely at the mercy of the debug info generated by the compiler. > I'd suggest not using -fprofile-arcs with VCov (and I'll put that in the docs). > Other than that, I don't have much to add. As already said, the problem is not specific to your VCov, I just used it because no additional program (kcachegrind) is required to view the statistics. All Valgrind tools (cachegrind, callgrind, covergrind) have the same problem, which suggests, that the problem is of general nature with valgrind. Best regards, Robert PS: I ran into a lot of trouble installing ggcov on my Suse9.3 box. If someone knows of another GUI for gcov, please let me know. |
|
From: Nicholas N. <nj...@cs...> - 2008-02-07 21:19:04
|
On Thu, 7 Feb 2008, Lieske, Robert wrote: > When helloworld.c is compiled without -fprofile-arcs, the valgrind-tools > report the correct result of 87.5% (7 of 8 lines). > The parameter -test-coverage is not related to the problem, it solely > depends on parameter -fprofile-arcs. Interesting. VCov is entirely at the mercy of the debug info generated by the compiler. I'd suggest not using -fprofile-arcs with VCov (and I'll put that in the docs). Other than that, I don't have much to add. N |
|
From: Tom H. <to...@co...> - 2008-02-07 12:59:42
|
In message <200...@gm...>
Josef Weidendorfer <Jos...@gm...> wrote:
> On Thursday 07 February 2008, Oliver Gerlich wrote:
>> way to get it working correctly for this "not-instantiated template"
>> case... That's why I'm interested whether someone has found solution for
>> this.
>
> When the compiler does not instantiate a template, there is
> no code generated for that template, and there can not be any debug info
> for not existing code.
>
> Thus, any coverage tool purely based on the binary and its debug info
> has no way to know about the existance of template code without instantiation.
But equally the code can never be executed because it doesn't
exist. So you know what percentage of the code that actually
exists in your shipping executable is tested, you just don't
know about hypothetical code that might be created some day if
somebody instantiates a template differently.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Josef W. <Jos...@gm...> - 2008-02-07 12:50:14
|
On Thursday 07 February 2008, Oliver Gerlich wrote: > way to get it working correctly for this "not-instantiated template" > case... That's why I'm interested whether someone has found solution for > this. When the compiler does not instantiate a template, there is no code generated for that template, and there can not be any debug info for not existing code. Thus, any coverage tool purely based on the binary and its debug info has no way to know about the existance of template code without instantiation. To make this work, you need additional information from the compiler. Does gcov cover this issue? Josef |
|
From: Jaroslaw B. <jar...@gm...> - 2008-02-07 11:18:51
|
On 2/6/08, David L <id...@gm...> wrote: > > > > On Mon, Feb 4, 2008 at 5:57 AM, Jaroslaw Baranowski > <jar...@gm...> wrote: > > Hi, > > > > I'm trying to run Valgrind memcheck with following command line: > > > > $valgrind --leak-check=full --leak-resolution=high > > --show-reachable=yes --xml=$xml --track-fds=yes --db-attach=yes > > --run-libc-freeres=yes <my_program> > > > > As far as I understood for documentation --db-attach=yes should call > > gdb upon encountering an error. Hovever, Valgrind just prints out the > > errors (deliberately made in test program) and terminates. > > > > I am using Valgrind 3.3.0 from source tarball and gdb 6.7 on SUSE 10.1. > > > > Is there any way to remedy this situation? Or am I doing something wrong? > I also have had problems with db-attach: > http://bugs.kde.org/show_bug.cgi?id=153879 > > Your symptoms sound a little different, but db-attach doesn't work for me > either. > > David > > Hi all, Thanks for your reply David. It could be actually two different problems, as you get a prompt for GDB to attach while there is none in my case. I have also tried this on openSUSE 10.3 x86-64 with following enviroment: Linux version 2.6.22.16-0.2-default (geeko@buildhost) (gcc version 4.2.1 (SUSE Linux)) #1 SMP 2008/02/01 19:36:55 UTC GDB is: GNU gdb 6.6.50.20070726-cvs and valgrind is: valgrind-3.3.0 Same as on my other machine - not even a prompt for gdb to attach to process. |
|
From: Lieske, R. <Rob...@ca...> - 2008-02-07 10:37:41
|
Hi,
as I already mentioned, I found out, that the code coverage reported by
valgrind is dependend on compiler settings. It does not matter, whether
callgrind, cachegrind, covergrind or exp-vcov is used.
Here is a small testing setup to reproduce the problem:
Take the following sample code:
=======
/* HelloWorld.c */
#include <stdio.h>
main()
{
printf("Hello World \n");
int i = 0;
for (i = 0; i <= 5; i++) {
if (i > 5) {
printf("Wert von i: %d\n", i);
} else {
printf("zu klein...\n");
}
}
}
=======
As can be seen when run, the code in line #9 is not reached.
As I also want to use the results of gcov, I compile the code with the
command line:
$ gcc -g -O0 -o helloworld -fprofile-arcs -ftest-coverage helloworld.c
Then I run helloworld with valgrind (does not matter which tool is used,
the result with cachgrind, callgrind and covergrind is the same; just
requires another program (kchachegrind) to view the results):
$ valgrind --tool=exp-vcov helloworld
View the results:
$ perl /opt/VCOV/exp-vcov/vc_annotate vcov.out
... reports 100.0% (8 of 8 lines) coverage in helloworld.c.
As is seen, when the code is executed (or from code inspection *g*),
line #9 is not reached. This is also reported from gcov:
$ gcov helloworld.c
File 'helloworld.c'
Lines executed:85.71% of 7
When helloworld.c is compiled without -fprofile-arcs, the valgrind-tools
report the correct result of 87.5% (7 of 8 lines).
The parameter -test-coverage is not related to the problem, it solely
depends on parameter -fprofile-arcs.
Can you comment on this?
TIA,
Robert
PS: I will continue to evaluate gcov and its related tools. If you have
some experience to share, please drop me a mail.
|
|
From: Oliver G. <ol...@gm...> - 2008-02-07 10:33:52
|
Nicholas Nethercote wrote: > On Thu, 7 Feb 2008, Oliver Gerlich wrote: > >> that sounds quite like I was looking for. But one thing that I've >> wondered about in particular when using Valgrind for coverage is how >> it works with C++ templates? If a template is never instantiated, how >> can a coverage tool detect that there is source code that is never >> executed? Is that possible somehow? > > My tool just records which instructions get executed, and then maps that > back to the source code lines according to the debug info. It also > identifies source lines mentioned in the debug info which weren't > executed. So I don't know the answer to your question, it depends > entirely how GCC produces its debug info for templates, but I suspect > the lines of code within the template would end up marked as unexecuted. > > Nick Thanks for the explanation! I had tried to build a coverage tool myself which parses callgrind/cachegrind output files; but I have not found a way to get it working correctly for this "not-instantiated template" case... That's why I'm interested whether someone has found solution for this. Attached is an example where my coverage tool fails: while it explicitly marks templateFunction3 as not-executed, it doesn't mark templateFunction2 like that. You can see at http://img509.imageshack.us/img509/9682/cgctemplateexample1na6.png how it looks. Also, because of this, the "68% executed" number is wrong as well. Regards, Oliver Gerlich |
|
From: Lieske, R. <Rob...@ca...> - 2008-02-07 08:09:29
|
Hi, > www.valgrind.org was down for maintainance yesterday for a few hours = try again... its an firewall issue on my site. Using a different connection I was able to checkout from svn.valgrind.org. The autogen.sh is still the same. I needed to install another package (automake) to run the script and compile valgrind with covergrind. However I was kind of disappointed with the result, as I found out, that the reported coverage was dependend on compiler settings (-fprofile-arcs -ftest-coverage). Then I noticed that cachegrind and callgrind report the same wrong result. Let me check with VCov. I'll start a new thread then. Best regards, Robert |
|
From: Thiago I. <iz...@ya...> - 2008-02-07 03:59:54
|
Hi I'm using valgrind-3.4.0.SVN (I've noticed this with older versions as well) and gdb 6.5 on 64bit linux. When I attach gdb to my program running under valgrind the following occurs:
==15529== Conditional jump or move depends on uninitialised value(s)
==15529== at 0x55A093C: Manta::DynBVH::firstIntersects(Manta::BBox const&, Manta::RayPacket const&, Manta::DynBVH::IAData const&, float*) const (DynBVH.cc:238)
==15529== by 0x55A0D33: Manta::DynBVH::intersectNode(int, Manta::RenderContext const&, Manta::RayPacket&, Manta::DynBVH::IAData const&) const (DynBVH.cc:82)
==15529== by 0x55A0DB6: Manta::DynBVH::intersectNode(int, Manta::RenderContext const&, Manta::RayPacket&, Manta::DynBVH::IAData const&) const (DynBVH.cc:114)
==15529== by 0x55A1306: Manta::DynBVH::intersect(Manta::RenderContext const&, Manta::RayPacket&) const (DynBVH.cc:74)
==15529== by 0x55AEA8E: Manta::Group::intersect(Manta::RenderContext const&, Manta::RayPacket&) const (Group.cc:211)
==15529== by 0x52E7E8D: Manta::HardShadows::computeShadows(Manta::RenderContext const&, Manta::ShadowAlgorithm::StateBuffer&, Manta::LightSet const*, Manta::RayPacket&, Manta::RayPacket&) (HardShadows.cc:324)
==15529== by 0x55FD88A: Manta::Lambertian::shade(Manta::RenderContext const&, Manta::RayPacket&) const (Lambertian.cc:95)
==15529== by 0x52E61FE: Manta::Raytracer::traceRays(Manta::RenderContext const&, Manta::RayPacket&) (Raytracer.cc:76)
==15529== by 0x52D3CDF: Manta::SingleSampler::renderFragment(Manta::RenderContext const&, Manta::Fragment&) (SingleSampler.cc:168)
==15529== by 0x52C7554: Manta::TiledImageTraverser::renderImage(Manta::RenderContext const&, Manta::Image*) (TiledImageTraverser.cc:204)
==15529== by 0x52A0810: Manta::RTRT::internalRenderLoop(int, bool) (RTRT.cc:935)
==15529== by 0x52A2254: Manta::RTRT::beginRendering(bool) (RTRT.cc:523)
==15529== by 0x413605: main (manta.cc:497)
==15529==
==15529== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- y
==15529== starting debugger with cmd: /usr/bin/gdb -nw /proc/15531/fd/1024 15531
GNU gdb 6.5
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-suse-linux"...Using host libthread_db library "/lib64/libthread_db.so.1".
Attaching to program: /proc/15531/fd/1024, process 15531
0x00000000055a093c in ?? ()
(gdb) where
#0 0x00000000055a093c in ?? ()
#1 0x00000007feff1380 in ?? ()
#2 0x00000000055a0d34 in ?? ()
#3 0x303600000063c588 in ?? ()
#4 0x0000000007668d88 in ?? ()
#5 0x0000000000000028 in ?? ()
#6 0x0000000000003800 in ?? ()
#7 0x2000000000000000 in ?? ()
#8 0x00000000078ce440 in ?? ()
#9 0x00000000078ccc10 in ?? ()
#10 0x0000000000000000 in ?? ()
I clearly have debugging symbols since valgrind can find them and if I run gdb directly on my program everything also works fine. What should I do to be able to debug my code with gdb?
Thanks,
Thiago
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
|
|
From: Nicholas N. <nj...@cs...> - 2008-02-07 00:34:34
|
On Thu, 7 Feb 2008, Oliver Gerlich wrote: > that sounds quite like I was looking for. But one thing that I've wondered > about in particular when using Valgrind for coverage is how it works with C++ > templates? If a template is never instantiated, how can a coverage tool > detect that there is source code that is never executed? Is that possible > somehow? My tool just records which instructions get executed, and then maps that back to the source code lines according to the debug info. It also identifies source lines mentioned in the debug info which weren't executed. So I don't know the answer to your question, it depends entirely how GCC produces its debug info for templates, but I suspect the lines of code within the template would end up marked as unexecuted. Nick |
|
From: Oliver G. <ol...@gm...> - 2008-02-06 23:19:32
|
Nicholas Nethercote schrieb: > [Forwarding this from the valgrind-developers list in response to a query > from Robert Lieske about coverage tools]] > > ---------- Forwarded message ---------- > Date: Mon, 4 Feb 2008 10:06:34 +1100 (EST) > From: Nicholas Nethercote <nj...@cs...> > To: Valgrind Developers <val...@li...> > Subject: [Valgrind-developers] Experimental Valgrind coverage tool > > Hi, > > I've written an experimental Valgrind coverage tool, called VCov. To try it > out, do this: > > svn co svn://svn.valgrind.org/valgrind/branches/VCOV > > Then build in the usual way (see the README file). To run it, use 'valgrind > --tool=exp-vcov <program>'. > > It's pretty simple. It just records, for each line of source code, how many > instructions that were derived from that line were executed. It aggregates > data from multiple executions. It all goes in a file called "vcov.out". [...] Hi, that sounds quite like I was looking for. But one thing that I've wondered about in particular when using Valgrind for coverage is how it works with C++ templates? If a template is never instantiated, how can a coverage tool detect that there is source code that is never executed? Is that possible somehow? Regards, Oliver Gerlich |
|
From: Nicholas N. <nj...@cs...> - 2008-02-06 21:11:31
|
[Forwarding this from the valgrind-developers list in response to a query
from Robert Lieske about coverage tools]]
---------- Forwarded message ----------
Date: Mon, 4 Feb 2008 10:06:34 +1100 (EST)
From: Nicholas Nethercote <nj...@cs...>
To: Valgrind Developers <val...@li...>
Subject: [Valgrind-developers] Experimental Valgrind coverage tool
Hi,
I've written an experimental Valgrind coverage tool, called VCov. To try it
out, do this:
svn co svn://svn.valgrind.org/valgrind/branches/VCOV
Then build in the usual way (see the README file). To run it, use 'valgrind
--tool=exp-vcov <program>'.
It's pretty simple. It just records, for each line of source code, how many
instructions that were derived from that line were executed. It aggregates
data from multiple executions. It all goes in a file called "vcov.out".
To interpret the data, run this command:
perl exp-vcov/vc_annotate vcov.out
The output gives total, per-file and per-line coverage. An example:
--------------------------------------------------------------------------------
Total coverage
--------------------------------------------------------------------------------
100.0% ( 9 of 9 lines)
--------------------------------------------------------------------------------
Per-file coverage (files with the most unexecuted lines are shown first)
--------------------------------------------------------------------------------
100.0% ( 3 of 3 lines): /home/njn/grind/trunk9/b.h
100.0% ( 6 of 6 lines): /home/njn/grind/trunk9/a.c
--------------------------------------------------------------------------------
/home/njn/grind/trunk9/b.h
--------------------------------------------------------------------------------
-: 1:__inline__ int foo(void)
4: 2:{
2: 3: return 0;
4: 4:}
--------------------------------------------------------------------------------
/home/njn/grind/trunk9/a.c
--------------------------------------------------------------------------------
-: 1:#include <stdio.h>
-: 2:#include "b.h"
-: 3:
-: 4:int main(int argc, char* argv[])
20: 5:{
4: 6: if (argc < 2)
5: 7: printf("hello, world\n");
-: 8: else
4: 9: printf("hello, extended world\n");
-: 10:
2: 11: return foo();
4: 12:}
--------------------------------------------------------------------------------
Total coverage
--------------------------------------------------------------------------------
88.9% ( 8 of 9 lines)
--------------------------------------------------------------------------------
Per-file coverage (files with the most unexecuted lines are shown first)
--------------------------------------------------------------------------------
83.3% ( 5 of 6 lines): /home/njn/grind/trunk9/a.c
100.0% ( 3 of 3 lines): /home/njn/grind/trunk9/b.h
--------------------------------------------------------------------------------
/home/njn/grind/trunk9/b.h
--------------------------------------------------------------------------------
-: 1:__inline__ int foo(void)
2: 2:{
1: 3: return 0;
2: 4:}
--------------------------------------------------------------------------------
/home/njn/grind/trunk9/a.c
--------------------------------------------------------------------------------
-: 1:#include <stdio.h>
-: 2:#include "b.h"
-: 3:
-: 4:int main(int argc, char* argv[])
10: 5:{
2: 6: if (argc < 2)
5: 7: printf("hello, world\n");
-: 8: else
#####: 9: printf("hello, extended world\n");
-: 10:
1: 11: return foo();
2: 12:}
Non-executable lines are preceded with '-'. Lines that are executable but
not executed are preceded with '######', so they are obvious.
There are lots of shortcomings, but it gets the general idea across. Some
things worth noting:
- Files not compiled with -g won't have any results.
- You can use the --fresh=yes option to overwrite any prior coverage data.
- I plan to add the ability to change the name of the output file.
- Results with --trace-children will be suspect, as there is no file locking
done yet on the output file.
- I hope to add some kind of branch coverage info, at least for the
encountered branches.
- If your program has a file for which no code is executed, it won't get
included in the output.
- I plan to add the ability to be more selective about which files get
annotated (currently every file that has been executed and that can be
found is annotated).
Any comments are welcome.
Nick
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Valgrind-developers mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-developers
|
|
From: Nicholas N. <nj...@cs...> - 2008-02-06 21:10:19
|
On Wed, 6 Feb 2008, Lieske, Robert wrote: > I want to compute code coverage with valgrind. I just committed a coverage tool to a branch. I'll forward to this list the message I sent to the developers list. I haven't tried Covergrind, so I don't know how it compares to my tool. Nick |