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
(5) |
2
(1) |
3
(2) |
4
(2) |
5
(9) |
|
6
|
7
(1) |
8
(2) |
9
(18) |
10
(4) |
11
(2) |
12
|
|
13
|
14
|
15
|
16
|
17
|
18
|
19
|
|
20
|
21
|
22
(15) |
23
(11) |
24
(17) |
25
(7) |
26
(2) |
|
27
|
28
(9) |
29
(3) |
30
|
|
|
|
|
From: Bart V. A. <bar...@gm...> - 2008-04-09 17:41:56
|
On Wed, Apr 9, 2008 at 6:12 PM, gleepglop <dar...@ga...> wrote: > > Bart Van Assche wrote: > > > > Did you already try VG_(get_data_description)() ? > > Yes, I did, and both dname1, and dname2 seemed to just return empty strings, > even for the globals that get_datasym_and_offset returned names for. VG_(get_data_description)() only works if you call VG_(needs_var_info)() from your tool's pre_clo_init() or post_clo_init() function first. Bart. |
|
From: Prashant K S <ks...@gm...> - 2008-04-09 16:21:41
|
Thanks a lot. This is indeed the case. On 4/9/08, Josef Weidendorfer <Jos...@gm...> wrote: > > On Wednesday 09 April 2008, Prashant K S wrote: > > reason. If you can see the PROGRAM TOTALS value is less than the > indvidual > > functions. I didn't understand this representation. > > It would be appropriate for callgrind_annotate to check for this and > put out a warning like this (however, this should at least be mentioned > in the manual). > > "WARNING: > Some inclusive cost collected by callgrind for your program is more than > 100% of the total cost. This indicates that there are recursive function > cycles executed in your code which screw up inclusive cost collection. For > correct output, a cycle detection post-processing needs to be done, which > currently is not implemented in callgrind_annotate. > Please use KCachegrind, which handles this case correctly. Also, check the > manual chapter about cycle avoidance approaches available in Callgrind." > > > Can you please explain. > > Also if there is a function by name A::func(), in some lines it is > printed > > as A::func()'2. What does the '2 indicate? > > Callgrind can distinguish recursion levels up to a given level. The > default > is 2 (to not exhaust memory), which means that function'2 contains all the > cost > happening at any recursion of function with level >= 2. The existance of > such > a function also explains the inclusive cost>100% in your case. > You can raise this value e.g. by using "--separate-recs=20", which > potentially > gets rid of any cycles and then, gives correct inclusive cost. > > Josef > > > > > Regards, > > Prashant > > > |
|
From: gleepglop <dar...@ga...> - 2008-04-09 16:12:52
|
Bart Van Assche wrote: > > > Did you already try VG_(get_data_description)() ? > > Bart. > > > Yes, I did, and both dname1, and dname2 seemed to just return empty strings, even for the globals that get_datasym_and_offset returned names for. Should VG_(get_data_description)() and VG_(get_datasym_and_offset)() definitely return some info for local/stack variables? What if the locals only exist in registers? (that can happen, right?) I compiled a stupid little C program with some globals and a single function (besides main) with some locals. And I put some random addition operations in the function using the locals and the globals. I compiled as: gcc -g test.c For the tool, I just changed lackey a little bit. I added calls to VG_(get_data_description)() and VG_(get_datasym_and_offset)() inside of the trace_load() and trace_store() helper functions and printf'd the results in those functions. And I modified the trace-mem stuff to only run on instructions inside of the function specified with the --fnname option. -- View this message in context: http://www.nabble.com/how-to-get-local-variable-name-from-data-address-tp16579254p16589561.html Sent from the Valgrind - Users mailing list archive at Nabble.com. |
|
From: Josef W. <Jos...@gm...> - 2008-04-09 16:08:12
|
On Wednesday 09 April 2008, Prashant K S wrote: > reason. If you can see the PROGRAM TOTALS value is less than the indvidual > functions. I didn't understand this representation. It would be appropriate for callgrind_annotate to check for this and put out a warning like this (however, this should at least be mentioned in the manual). "WARNING: Some inclusive cost collected by callgrind for your program is more than 100% of the total cost. This indicates that there are recursive function cycles executed in your code which screw up inclusive cost collection. For correct output, a cycle detection post-processing needs to be done, which currently is not implemented in callgrind_annotate. Please use KCachegrind, which handles this case correctly. Also, check the manual chapter about cycle avoidance approaches available in Callgrind." > Can you please explain. > Also if there is a function by name A::func(), in some lines it is printed > as A::func()'2. What does the '2 indicate? Callgrind can distinguish recursion levels up to a given level. The default is 2 (to not exhaust memory), which means that function'2 contains all the cost happening at any recursion of function with level >= 2. The existance of such a function also explains the inclusive cost>100% in your case. You can raise this value e.g. by using "--separate-recs=20", which potentially gets rid of any cycles and then, gives correct inclusive cost. Josef > > Regards, > Prashant > |
|
From: Christoph B. <bar...@or...> - 2008-04-09 11:50:35
|
Am Mittwoch, 9. April 2008 schrieb Lee, Dio: > It's multithreaded. You could run it with callgrind valgrind --tool=callgrind till it hangs and then print out a traceback: callgrind_control -b Then you see how you produced the deadlock. Christoph |
|
From: Prashant K S <ks...@gm...> - 2008-04-09 09:43:39
|
Hi,
I am trying to use the callgrind tool. I am using the option --instr-atstart=no
so that instrumentation does not start at beginning. At some point I switch
the instrumentation on by calling callgrind_control -i on. So I assume the
instrumentation starts at this point. Now I interrupt my process and there
by killing it. Now a dump callgrind.out.1424 is generated. I run
callgrind_annotate --inclusive=yes callgrind.out.1424 >out.txt. Now the
out.txt has the out put in the below format. There are function names after
??? on each line. I have removed the name because of proprietory information
reason. If you can see the PROGRAM TOTALS value is less than the indvidual
functions. I didn't understand this representation. Can you please explain.
Also if there is a function by name A::func(), in some lines it is printed
as A::func()'2. What does the '2 indicate?
Regards,
Prashant
--------------------------------------------------------------------------------
Profile data file 'callgrind.out.1424' (creator: callgrind-3.3.0)
--------------------------------------------------------------------------------
I1 cache:
D1 cache:
L2 cache:
Timerange: Basic block 0 - 9610908
Trigger: Program termination
Profiled target: process name with args(PID 1424, part 1)
Events recorded: Ir
Events shown: Ir
Event sort order: Ir
Thresholds: 99
Include dirs:
User annotated:
Auto-annotation: off
--------------------------------------------------------------------------------
Ir
--------------------------------------------------------------------------------
55,319,754 PROGRAM TOTALS
--------------------------------------------------------------------------------
Ir file:function
--------------------------------------------------------------------------------
110,633,950 ???:
110,600,478 ???:
109,597,596 ???:
65,273,219 ???:
55,317,147 ???:
55,316,595 ???:
54,451,919 ???:
54,446,777 ???:
50,481,955 ???:
48,717,035 ???:
48,714,091 ???:
48,309,314 ???:
48,307,034 ???:
45,603,233 ???:
45,599,050 ???:
45,522,180 ???:
45,422,355 ???:
25,867,267 ???:
24,022,839 ???:
20,481,756 ???:
17,996,392 ???:
16,789,430 ???:
15,539,320 ???:
13,684,120 ???:
13,615,214 ???:
12,092,398 ???:
12,090,770 ???:
11,268,782 ???:
9,567,567 ???:
9,566,169 ???:
9,507,190 ???:
9,299,070 ???:
8,813,507 ???:
8,787,293 ???:
7,805,162 ???:
6,443,845 ???:
5,251,893 ???:
5,247,271 ???:
4,977,293 ???:
4,914,519 ???:
4,826,971 ???:
4,688,683 ???:
4,684,039 ???:
4,571,908 ???:
4,568,905 ???:
4,385,765 ???:
4,295,475 ???:
4,220,146 ???:
4,147,336 ???:
4,062,689 ???:
4,014,449 ???:
3,671,449 ???:
3,591,933 ???:
3,548,294 ???:
3,467,962 ???:
3,464,919 ???:
3,375,023 ???:
3,296,902 ???:
3,270,883 ???:
3,194,663 ???:
3,188,035 ???:
3,186,651 ???:
3,150,789 ???:
3,137,166 ???:
3,072,942 ???:
2,981,427 ???:
2,934,276 ???:
2,696,537 ???:
2,624,329 ???:
2,623,898 ???:
2,611,841 ???:
2,588,039 ???:
2,512,174 ???:
2,487,714 ???:
2,373,992 ???:
2,328,047 ???:
2,312,723 ???:
2,311,032 ???:
2,269,224 ???:
2,237,006 ???:
2,232,487 ???:
2,228,546 ???:
2,208,000 ???:
2,191,573 ???:
2,181,806 ???:
2,139,270 ???:
2,084,422 ???:
2,067,134 ???:
2,059,064 ???:
2,026,768 ???:
2,003,622 ???:
1,970,744 ???:
1,967,608 ???:
1,955,486 ???:
1,940,001 ???:
1,934,295 ???:
1,826,497 ???:
1,811,127 ???:
1,810,326 ???:
1,809,958 ???:
1,758,136 ???:
1,735,937 ???:
1,658,495 ???:
1,586,599 ???:
1,551,344 ???:
1,493,343 ???:
1,363,885 ???:
1,304,232 ???:
1,122,932 ???:
1,075,669 ???:
928,566 ???:
921,776 ???:
912,679 /hom
884,737 ???:
884,683 ???:
882,208 /hom
861,894 /hom
780,265 ???:
725,004 ???:
704,030 ???:
701,150 ???:
622,112 ???:
604,368 ???:
583,746 ???:
574,951 ???:
573,478 ???:
563,164 ???:
560,842 ???:
555,662 ???:
526,627 ???:
|
|
From: Bart V. A. <bar...@gm...> - 2008-04-09 07:06:09
|
On Wed, Apr 9, 2008 at 8:30 AM, Lee, Dio <Di...@ch...> wrote: > It's multithreaded. Programs run slower under memcheck than native, which may trigger deadlocks in improperly written programs. Did you already analyze your program via helgrind's locking order checking or via exp-drd's synchronization operation tracing options ? Bart. |
|
From: Lee, D. <Di...@ch...> - 2008-04-09 06:30:54
|
It's multithreaded. ________________________________________ From: Bart Van Assche [bar...@gm...] Sent: Wednesday, April 09, 2008 2:14 PM To: Lee, Dio Cc: val...@li... Subject: Re: [Valgrind-users] Why valgrind hang-up my program? On Tue, Apr 8, 2008 at 3:40 AM, Lee, Dio <Di...@ch...> wrote: > I am checking memory leak in my program by valgrind. > > Use command line: > $valgrind --tool=memcheck --leak-check=full ./testbin > But it hang-up sometimes, and hang-up at random point. I have look into the valgrind log, but get nothing error or warning there. > > What should I do to solve this problem? Any suggestion will be helpful, thanks. Is your program single-threaded or multithreaded ? Bart. |
|
From: Bart V. A. <bar...@gm...> - 2008-04-09 06:14:46
|
On Tue, Apr 8, 2008 at 3:40 AM, Lee, Dio <Di...@ch...> wrote: > I am checking memory leak in my program by valgrind. > > Use command line: > $valgrind --tool=memcheck --leak-check=full ./testbin > But it hang-up sometimes, and hang-up at random point. I have look into the valgrind log, but get nothing error or warning there. > > What should I do to solve this problem? Any suggestion will be helpful, thanks. Is your program single-threaded or multithreaded ? Bart. |
|
From: Bart V. A. <bar...@gm...> - 2008-04-09 06:09:31
|
On Wed, Apr 9, 2008 at 7:25 AM, gleepglop <dar...@ga...> wrote: > > I found the function > VG_(get_datasym_and_offset)( Addr data_addr, > /*OUT*/Char* dname, Int n_dname, > /*OUT*/OffT* offset ) > > and this seems to work for global variables. But for local variables, it > seems to just return the name "temporary". > But I assume there must be a way to derive the names associated with a stack > variable from the debug info. Perhaps taking the address minus the stack > pointer value, and scanning the debug info for that result? Did you already try VG_(get_data_description)() ? > Uh, and as for pointers to heap data, I haven't put much thought into that > yet. Perhaps that's a much different problem. You can track all malloc() / free() calls in your tool. See e.g. memcheck for an example. Bart. |
|
From: gleepglop <dar...@ga...> - 2008-04-09 05:25:41
|
Hi, I am new to Valgrind and program understanding tools in general. (I have
used gdb once or twice, but I'm very much a novice to the nitty gritty
details of how programs work)
I wish to write a tool that creates points-to data such that for each
pointer access I can see what source code variable name the pointer was
pointing to.
That is, given a load or store address, I want to lookup in the debug info
what the variable name being accessed is.
I found the function
VG_(get_datasym_and_offset)( Addr data_addr,
/*OUT*/Char* dname, Int n_dname,
/*OUT*/OffT* offset )
and this seems to work for global variables. But for local variables, it
seems to just return the name "temporary".
But I assume there must be a way to derive the names associated with a stack
variable from the debug info. Perhaps taking the address minus the stack
pointer value, and scanning the debug info for that result?
Uh, and as for pointers to heap data, I haven't put much thought into that
yet. Perhaps that's a much different problem.
--
View this message in context: http://www.nabble.com/how-to-get-local-variable-name-from-data-address-tp16579254p16579254.html
Sent from the Valgrind - Users mailing list archive at Nabble.com.
|
|
From: Nicholas N. <nj...@cs...> - 2008-04-09 05:06:06
|
On Tue, 8 Apr 2008, David Tweed wrote: > I've got a program that I'm attempting to generate cache statistics > for. After a make clean and remaking (so there's no possibility of a > mismatch between source and executable), I'm finding the cg_annotate > (on produced cachegrind.out.8728 files) is repeatedly reporting things > like > > ------------------------------------------8<----------------------------------- > . . . . . . . . . > deallocate1DArray(sums,2*noObjs); > 11 2 2 4 0 0 3 0 0 } > 7 1 1 2 0 0 2 0 0 > <bogus line 1026> > > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ > @@ WARNING @@ WARNING @@ WARNING @@ WARNING @@ WARNING @@ WARNING @@ WARNING @@ > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ > @@ > @@ Information recorded about lines past the end of > '/home/sis05dst/PRG_DEV/KDEV/TESTING/ARCHITECTURE/benefitCacheCare/simdImageRoutines.cc > '. > @@ > @@ Probable cause and solution: > @@ cause: not sure, sorry > @@ > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Cachegrind produces an output file that indicates how many times each line of code was executed (plus some other stuff). What's happened here is that Cachegrind is generating statistics for one or more lines that appear not to exist in the file. Eg. it's got numbers for line 500 in a file that has only 400 lines in it. It's unclear why this might be happening. Perhaps the debug info generated by the compiler is bogus? That's what Cachegrind uses to identify which lines are executed. Nick |
|
From: Julian S. <js...@ac...> - 2008-04-09 00:52:17
|
Hello all, Valkyrie is a Qt3-based GUI for the Valgrind's Memcheck tool. It works with Valgrind versions 3.0.0 through 3.2.3 (unfortunately not the current 3.3.0 release) and is available at http://www.valgrind.org/downloads/valkyrie-1.2.0.tar.bz2. Valkyrie development has, unfortunately, stalled, due to time constraints. This state of affairs does not look likely to change in the near-to-medium future. I have been contacted by a few developers who are interested in pushing things along. If you are a developer and are interested in working on Valkyrie, there is a Valkyrie mailing list you can subscribe to: https://lists.sourceforge.net/lists/listinfo/valgrind-valkyrie-dev. The current To-do list looks like this: - Make Valkyrie work with the current (3.3.X) version of Valgrind. This should be easy: in 3.3.0, Valgrind's "--log-file-exactly=" option was renamed to "--log-file=", and so Valkyrie's option should be renamed accordingly. - The path for the Help contents files are hard-coded to /usr/doc. Documentation is therefore not visible unless the Helpviewer is pointed to the right files. Also, there is no way to set paths. - The path on where to save the output to is also hard-coded to /home/<acct>/.valkyrie/logs. - Valkyrie sometimes fails to run valgrind on a binary, and gives an error message: Process exited with return value 1. This is likely to simply be the client program return value. If, however, you suspect Valgrind itself may have crashed, please 'Save Log' and examine for details. BUT "Save Log" is currently disabled. - On exit, the Valkyrie prompts to save the output or not. When "Save" is clicked, a file dialog opens. Sometimes save fails, and then the user has to discard the output. - Support for Massif and Cachegrind seems to be wanted by quite a few users. - Porting to QT4 is a must. |
|
From: David T. <dav...@gm...> - 2008-04-08 11:05:48
|
Hi,
I've got a program that I'm attempting to generate cache statistics
for. After a make clean and remaking (so there's no possibility of a
mismatch between source and executable), I'm finding the cg_annotate
(on produced cachegrind.out.8728 files) is repeatedly reporting things
like
------------------------------------------8<-----------------------------------
. . . . . . . . .
deallocate1DArray(sums,2*noObjs);
11 2 2 4 0 0 3 0 0 }
7 1 1 2 0 0 2 0 0
<bogus line 1026>
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@ WARNING @@ WARNING @@ WARNING @@ WARNING @@ WARNING @@ WARNING @@ WARNING @@
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@
@@ Information recorded about lines past the end of
'/home/sis05dst/PRG_DEV/KDEV/TESTING/ARCHITECTURE/benefitCacheCare/simdImageRoutines.cc
'.
@@
@@ Probable cause and solution:
@@ cause: not sure, sorry
@@
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
------------------------------------------8<-----------------------------------
Some of the detailed cache statistics on many of the lines look wrong,
but that may be my misunderstanding of my program's behaviour. One
observation is that I only get these on source files I've written, for
headers like
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/include/emmintrin.h
and
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_pair.h
I don't get these error messages.
This is with the program compiled with g++ ("g++ (GCC) 4.1.2 20070925
(Red Hat 4.1.2-27)") at -g (although I later want to use "-O2 -g" so
that the SIMD intrinsic functions actually get inlined into one
machine instruction rather than a function call and machine
instruction). The valgrind version is SVN from about a month ago,
modified with an analogue of Nick Nethercote's patch for massif for
putting statistics for fork()'d processes in files named with the
correct PID. This is because the program starts, sets up some big data
structures and then fork()'s a couple of times, with each child then
running an intensive computation in the child; it's these child
processes I'm really interested in the cache stats on. (I can dig up
the patch if it's important, but I literally copied the massif patch
operations at the same points in cachegrind.)
Does anyone have any ideas on what could be wrong with my setup? Is it
likely that the cache statistics are generally correct with some
strange bits at the end of files, or is it likely that every line's
cache stats are incorrect?
Many thanks for any insight and assistance,
--
cheers, dave tweed__________________________
dav...@gm...
Rm 124, School of Systems Engineering, University of Reading.
"while having code so boring anyone can maintain it, use Python." --
attempted insult seen on slashdot
|
|
From: Lee, D. <Di...@ch...> - 2008-04-08 01:40:30
|
Dear All, I am checking memory leak in my program by valgrind. Use command line: $valgrind --tool=memcheck --leak-check=full ./testbin But it hang-up sometimes, and hang-up at random point. I have look into the valgrind log, but get nothing error or warning there. What should I do to solve this problem? Any suggestion will be helpful, thanks. |
|
From: Florian K. <br...@ac...> - 2008-04-07 04:14:18
|
On Sunday 23 March 2008 6:36:43 pm Martijn Versteegh wrote: > Hello all, > > I made a very simple first version of a program to visualize the output > of the massif tool. Since I don't have too much free time on my hands I > had some doubts about releasing it now, since I'm not sure if I'll have > the time to do something with any comments I'll (hopefully) get. > > I decided to put it up somewhere anyway so that somebody won't need to > do any work which has already been done ;-) > > You can check it out here > > http://www.aaltjegron.nl/msplot/ > > Please let me know what you think about it. > I this supposed to compile on GNU/Linux? With gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21), libwxbase2.60 and libwxgtk2.4-1 I'm getting: g++ -O3 -Wall -g -Werror -DDEBUGMODE `wx-config --cxxflags` -c wxmain.cpp -o obj/wxmain.o wxmain.cpp: In constructor 'MyFrame::MyFrame(const wxString&)': wxmain.cpp:238: error: 'wxSizerFlags' was not declared in this scope wxmain.cpp: In member function 'void MyFrame::OnOpen(wxCommandEvent&)': wxmain.cpp:325: error: 'wxFD_OPEN' was not declared in this scope wxmain.cpp:325: error: 'wxFD_FILE_MUST_EXIST' was not declared in this scope Perhaps you could document a working combination of tools/dependencies. That'll help with getting some feedback ;) Florian |
|
From: Julian S. <js...@ac...> - 2008-04-05 20:32:56
|
> for each statement s in the IRBB
> if s is an Ist_Store
> then
> insert helper function with argument s->Ist.Store.data
> endif
>
> if s is an Ist_Tmp
> then
> if tag of IRExpr in s->Ist.Tmp.Data is Iex_Load
> insert helper function with argument s->Ist.Tmp.tmp
> endif
> end
To get 100% coverage, you also need to handle Ist_Dirty, which is tricky.
> * Issue: The VEX core only handles arguments of type Ity_I32 passed to
> helper functions. [...]
> Solution 1: at instrumentation time, use the tyenv array in the basic block
> to check
> the type of the temporary variable tX . If tX is not Ity_I32, insert a new
> IRStmt which allocates a new temporary tZ and inserts a conversion from the
> type of tX to Ity_I32, then inserts a call to checkValueAndPrintST(tZ). I
> have not actually done this, but it "should work."
Yes - it's by far the simplest solution, and is used in various
tools. Basically widen the arg using Iop_{1,8,16}Uto32 before
handing it to the helper call.
J
|
|
From: David M. <dm...@gm...> - 2008-04-05 18:30:50
|
On Sat, Apr 5, 2008 at 5:37 AM, Ian Lynagh <ig...@ea...> wrote:
>
>
> If so, I should be able to do it by writing a new tool, right?
> I had a look at doing so, but got stuck. Does anyone have any pointers
> on the best way to approach this please?
>
I second the suggestion to look at Lackey - it really is a wonderful example
tool.
That being said, here is one possible design for your tool which may make
some sense after you've looked at Lackey. It probably isn't the best way of
doing things, so maybe others will have thoughts.
1) Create a helper function
void checkValueAndPrintST(HWord value)
This function will take as an argument the value stored to or loaded from
memory. It checks the value is equal to 1 mod 8, then if so calls
VG_(get_and_pp_StackTrace) as Julian said. Our goal will be to add this
helper function into an IRBB after each stor statement and after each
expression which includes a load expression. We want to pass the helper
function an expression which evaluates to the value stored or loaded.
For example, if the original IRBB has the statement
t5 = LDle:I32(0xDEADBEEF);
the new IRBB after the tool is done will add a statement something like this
following
DIRTY 1:I1 ::: checkValueAndPrintST{0x3800a27c}(t5)
2) In the main IRBB instrumentation callback (this is lk_instrument in
lk_main.c), do the following:
for each statement s in the IRBB
if s is an Ist_Store
then
insert helper function with argument s->Ist.Store.data
endif
if s is an Ist_Tmp
then
if tag of IRExpr in s->Ist.Tmp.Data is Iex_Load
insert helper function with argument s->Ist.Tmp.tmp
endif
end
Note this assumes the Ist.Store.data is always a single temporary variable,
and that there are no compound expressions involving Iex_Load on the right
hand side of an Ist_Tmp. The Ist.Store.data I haven't seen an exception, but
there are a few I think for the second. You can look for such behaviour by
running your program with --trace-flags=0100000 and --trace-notbelow=0,
which shows the IR as it is passed to your tool.
Some things to note with this approach:
* Issue: The VEX core only handles arguments of type Ity_I32 passed to
helper functions. If you try to pass an Ity_I1, Ity_I16, etc. you will hit a
sanity check error during the compilation of your instrumented basic block.
(At least, as of release 3.2, maybe it is different now).
Solution 0: hack the VEX core to properly pass different arguments on your
specific architecture(s). I have done this. It has the usual problems of
requiring new work for different architectures, plus your tool now will not
work with future Valgrind releases. It is quick to implement for Ity_I1,
Ity_I16, etc. however.
Solution 1: at instrumentation time, use the tyenv array in the basic block
to check
the type of the temporary variable tX . If tX is not Ity_I32, insert a new
IRStmt which allocates a new temporary tZ and inserts a conversion from the
type of tX to Ity_I32, then inserts a call to checkValueAndPrintST(tZ). I
have not actually done this, but it "should work."
* Issue: When adding many statements to a basic block which is already
large, it is possible to overrun the VEX translation buffer during the
compilation of the instrumented IRBB. (I've seen this with libjpg.)
Solution: Increase the size of the VEX translation buffer. You need to
modify
#define N_TMPBUF 20000
in /coregrind/m_translate.c
and also an assertion
vg_assert(code_len > 0 && code_len < 20000);
in coregrind/m_transtab.c .
hope this is useful, good luck with your tool,
-David Molnar
|
|
From: Ian L. <ig...@ea...> - 2008-04-05 15:43:49
|
On Sat, Apr 05, 2008 at 05:04:49PM +0200, Julian Seward wrote: > > > Thanks for the reply. However, that sounds like it is going to tell me > > when any value is written to/read from the address 0x40D4F000. > > > > I want to know when the value 0x40D4F000 is written to/read from any > > address. > > Oh, my mistake. So, don't try to write a tool from scratch (far too > much effort). Instead, first play around with --tool=lackey, and then > hack around lk_main.c to make it do what you want. > > At some point, when you're in the relevant helper function, and you > want to "show" where the program is, do this > > ThreadId tid = VG_(get_running_tid)(); > VG_(get_and_pp_StackTrace) ( tid, 12 ); Thanks! Ian |
|
From: Bart V. A. <bar...@gm...> - 2008-04-05 15:33:49
|
On Sun, Mar 30, 2008 at 4:20 PM, Ivan Skytte Jørgensen <isj...@i1...> wrote: > On Sunday 30 March 2008 12:25:46 Bart Van Assche wrote: > [snip] > > > * Handle reader-writer locking objects as if their implementation was > > based on a single mutex M and as if the operations on these locking > > objects were implemented as follows: > > - Obtaining a reader lock is equivalent to locking + unlocking mutex M. > > - Unlocking a reader lock is equivalent to locking + unlocking mutex M. > > - Obtaining a writer lock is equivalent to locking mutex M. > > - Unlocking a writer lock is equivalent to unlocking mutex M. > > It does not catch this scenario: > > thread 1: > readlock A > writelock B > unlock B > unlock A > thread 2: > readlock B > writelock A > unlock A > unlock B Would you consider it acceptable for a tool that verifies the locking order to complain whenever it is attempted to obtain a writer lock nested inside a reader lock ? Bart. |
|
From: Julian S. <js...@ac...> - 2008-04-05 15:09:17
|
> Thanks for the reply. However, that sounds like it is going to tell me > when any value is written to/read from the address 0x40D4F000. > > I want to know when the value 0x40D4F000 is written to/read from any > address. Oh, my mistake. So, don't try to write a tool from scratch (far too much effort). Instead, first play around with --tool=lackey, and then hack around lk_main.c to make it do what you want. At some point, when you're in the relevant helper function, and you want to "show" where the program is, do this ThreadId tid = VG_(get_running_tid)(); VG_(get_and_pp_StackTrace) ( tid, 12 ); J |
|
From: Ian L. <ig...@ea...> - 2008-04-05 13:28:09
|
On Sat, Apr 05, 2008 at 01:37:08PM +0100, Ian Lynagh wrote: > > I would like valgrind to give me a stack trace when a given value > (0x40D4F000) is written to or read from anywhere in memory. Actually, now I think about it, this bug is more likely to be caused by writing a pointer to an address that is 1 mod 8 (on amd64). Can valgrind tell me when I am doing that? Thanks Ian |
|
From: Ian L. <ig...@ea...> - 2008-04-05 13:07:45
|
Hi Julian, On Sat, Apr 05, 2008 at 02:50:13PM +0200, Julian Seward wrote: > On Saturday 05 April 2008 14:37, Ian Lynagh wrote: > > Hi all, > > > > I would like valgrind to give me a stack trace when a given value > > (0x40D4F000) is written to or read from anywhere in memory. > > valgrind-3.3.0 --tool=helgrind --trace-addr=0x40D4F000 --trace-level=2 ... Thanks for the reply. However, that sounds like it is going to tell me when any value is written to/read from the address 0x40D4F000. I want to know when the value 0x40D4F000 is written to/read from any address. Thanks Ian |
|
From: Julian S. <js...@ac...> - 2008-04-05 12:54:58
|
On Saturday 05 April 2008 14:37, Ian Lynagh wrote: > Hi all, > > I would like valgrind to give me a stack trace when a given value > (0x40D4F000) is written to or read from anywhere in memory. valgrind-3.3.0 --tool=helgrind --trace-addr=0x40D4F000 --trace-level=2 ... But really, if you just want to know when 0x40D4F000 is getting trashed (or read), you'd be better off using GDB's hardware watchpoint facility. Then the program can run at full speed and stop in GDB whenever the address is read/written. J |
|
From: Ian L. <ig...@ea...> - 2008-04-05 12:39:15
|
Hi all, I would like valgrind to give me a stack trace when a given value (0x40D4F000) is written to or read from anywhere in memory. Am I right in thinking that valgrind can't do this out of the box? If so, I should be able to do it by writing a new tool, right? I had a look at doing so, but got stuck. Does anyone have any pointers on the best way to approach this please? Thanks Ian |