You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
1
(17) |
2
(15) |
3
(36) |
4
(24) |
5
(36) |
|
6
(18) |
7
(16) |
8
(18) |
9
(19) |
10
(18) |
11
(37) |
12
(18) |
|
13
(13) |
14
(21) |
15
(27) |
16
(10) |
17
(16) |
18
(25) |
19
(21) |
|
20
(11) |
21
(14) |
22
(6) |
23
(15) |
24
(27) |
25
(3) |
26
(9) |
|
27
(16) |
28
(24) |
29
(21) |
30
(43) |
31
(42) |
|
|
|
From: Robert W. <rj...@du...> - 2005-03-06 20:07:55
|
> > That was the original idea. Then I realized that 1) we don't have any > > HTML documentation of a lot of those options anyway; >=20 > Really? Which ones? --trace-codegen for one. Well, there's documentation there, but it's not very extensive - it doesn't enumerate what your can trace, for example. Also --chain-bb, --avoid-strlen-errors, --command-line-only, --exec, --sanity-level and --trace-redir. OK - maybe "a lot" was an exaggeration, but I still prefer the idea of getting this documentation on the command-line instead of in a browser. Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Nicholas N. <nj...@cs...> - 2005-03-06 19:55:15
|
On Sun, 6 Mar 2005, Robert Walsh wrote: >> I'm getting '?' characters instead of hypens when words are split. > > Huh. Works OK for me. Might be something to do with your LANG > variable? Mine is en_US. I've seen man mess up royally before when it > was set to something else like en_US.UTF-8. Oh, I now see I'm getting it on all man pages. Sorry, ignore. >> My main comment is that I wouldn't have given nearly as much detail. > > That was the original idea. Then I realized that 1) we don't have any > HTML documentation of a lot of those options anyway; Really? Which ones? N |
|
From: Josef W. <Jos...@gm...> - 2005-03-06 19:30:51
|
Hi, On Saturday 05 March 2005 01:56, Julian Seward wrote: > It seems to me we should be very close to a 2.4.0 freeze. may I ask for a small set of additional tool API functions? I'm currently working on data structure related profiling info, and for that to be acceptable, I need to maintain a mapping table from address to objects. For static objects, I have to hook into symbol loading, and that is what the tool API addition is for. Josef |
|
From: Robert W. <rj...@du...> - 2005-03-06 19:28:32
|
> I'm getting '?' characters instead of hypens when words are split. Huh. Works OK for me. Might be something to do with your LANG variable? Mine is en_US. I've seen man mess up royally before when it was set to something else like en_US.UTF-8. > My main comment is that I wouldn't have given nearly as much detail. I=20 > would have just given the basics and then pointed at the user manual. I=20 > definitely wouldn't have described the debugging options. That was the original idea. Then I realized that 1) we don't have any HTML documentation of a lot of those options anyway; 2) I could never remember the syntax of the more obscure options (like, say, --trace-codegen) and searching for it in the HTML and source code was a pain. So I thought it would be a good idea to get all the options gathered together in one place. > I'm just=20 > worried about double maintenance. (It would be nice to auto-generate the=20 > man page from the manual section describing the command line args.) > But I don't want to be too negative, it's good to have a man page. Double maintenance is a problem, for sure, and the auto-generate idea crossed my mind more than once while I was doing this. Maybe the source code should be the golden source for all of this, with a perl script that strips the documentation and generates the options parts of the man page and HTML documentation? Like javadoc does for java. That way there's plenty of examples scattered around you when you add a new option. Any thoughts? Probably this shouldn't hold up 2.4.0, but it would be nice to have it for 3.0.0. Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Julian S. <js...@ac...> - 2005-03-06 15:05:45
|
> > * Put primary emphasis on better structure, clarity and > > maintainability of the system as a whole. I've noticed that > > neglect of these things over the long term is a leading cause > > of death/abandonment of software systems, and I don't want > > Valgrind to fall into that trap. > > I would guess that the structure stuff is a more long-term thing -- it can > certainly be started now, but I don't imagine everything can be > partitioned nicely before June. Yes, I was just thinking that. Fixing up the current merge, getting amd64 to work well, and rewriting the address-space manager are probably as much as is realistically achievable in that timeframe. J |
|
From: Nicholas N. <nj...@cs...> - 2005-03-06 05:39:53
|
On Sat, 5 Mar 2005, Julian Seward wrote: > What's between 2.4 and 3.0 ? What I want to do is: > > * Rewrite the low level memory manager, for the reasons already > discussed at length. > > * Restructure the coregrind/ swamp into separate, well-defined > subsystems. > > * Make amd64 work as well as x86. > > * Put primary emphasis on better structure, clarity and > maintainability of the system as a whole. I've noticed that > neglect of these things over the long term is a leading cause > of death/abandonment of software systems, and I don't want > Valgrind to fall into that trap. I would guess that the structure stuff is a more long-term thing -- it can certainly be started now, but I don't imagine everything can be partitioned nicely before June. N |
|
From: Nicholas N. <nj...@cs...> - 2005-03-06 04:47:45
|
On Sat, 5 Mar 2005, Robert Walsh wrote:
> There's a manual page now. It is installed, but not yet included in
> the .spec file. Jeremy: can you put it into the .spec file: I'm not
> sure how manual pages are normally handled in there.
>
> I'd appreciate feedback on the contents.
DESCRIPTION
valgrind is a flexible program for debugging and profiling
Linux-x86 executables. It consists of a core, which pro?
vides a synthetic x86 CPU in software, and a series of
"tools", each of which is a debugging or profiling tool.
The architecture is modular, so that new tools can be cre?
ated easily and without disturbing the existing structure.
I'm getting '?' characters instead of hypens when words are split.
My main comment is that I wouldn't have given nearly as much detail. I
would have just given the basics and then pointed at the user manual. I
definitely wouldn't have described the debugging options. I'm just
worried about double maintenance. (It would be nice to auto-generate the
man page from the manual section describing the command line args.)
But I don't want to be too negative, it's good to have a man page.
N
|
|
From: Robert W. <rj...@du...> - 2005-03-06 04:29:13
|
CVS commit by rjwalsh:
Update memcheck description. Comment out all mention of helgrind until
it's working again.
M +19 -14 valgrind.1 1.4
--- valgrind/docs/valgrind.1 #1.3:1.4
@@ -27,9 +27,13 @@
valgrind program args
-This runs \fBprogram\fP (with arguments \fBargs\fP) under valgrind using
-the \fBmemcheck\fP tool. To use a different tool, use the \fB--tool\fP
-option:
+This runs \fBprogram\fP (with arguments \fBargs\fP) under valgrind
+using the \fBmemcheck\fP tool. \fBmemcheck\fP performs a range of
+memory-checking functions, including detecting accesses to uninitialized
+memory, misuse of allocated memory (double frees, access after free,
+etc.) and detecting memory leaks.
- valgrind --tool=addrcheck program args
+To use a different tool, use the \fB--tool\fP option:
+
+ valgrind --tool=toolname program args
The following tools are available:
@@ -40,5 +44,6 @@
- addrcheck
\fBaddrcheck\fP is similar to memcheck, but does not perform the same
-granularity of memory checking.
+granularity of memory checking. This will run faster and use less memory,
+but may miss some problems that \fBmemcheck\fP would catch.
.TP
.B
@@ -403,15 +408,15 @@
have multiple stacks.
-.SH HELGRIND OPTIONS
+." .SH HELGRIND OPTIONS
-.TP
-.B
---private-stacks=<yes|no> [default: no]
-Assume thread stacks are used privately.
+." .TP
+." .B
+." --private-stacks=<yes|no> [default: no]
+." Assume thread stacks are used privately.
-.TP
-.B
---show-last-access=<yes|some|no> [default: no]
-Show location of last word access on error.
+." .TP
+." .B
+." --show-last-access=<yes|some|no> [default: no]
+." Show location of last word access on error.
.SH LESS FREQUENTLY USED CORE OPTIONS
|
|
From: <js...@ac...> - 2005-03-06 04:02:25
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2005-03-06 03:50:01 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int rm: cannot remove `vgcore.pid*': No such file or directory (cleanup operation failed: rm vgcore.pid*) pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 198 tests, 5 stderr failures, 0 stdout failures ================= memcheck/tests/pth_once (stderr) memcheck/tests/scalar (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/writev (stderr) corecheck/tests/fdleak_fcntl (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <to...@co...> - 2005-03-06 03:28:14
|
Nightly build on dunsmere ( Fedora Core 3 ) started at 2005-03-06 03:20:03 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_mmx: valgrind ./insn_mmx insn_mmxext: valgrind ./insn_mmxext insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int sh: line 1: 22059 Segmentation fault VALGRINDLIB=/tmp/valgrind.29434/valgrind/.in_place /tmp/valgrind.29434/valgrind/./coregrind/valgrind --command-line-only=yes --tool=none ./int >int.stdout.out 2>int.stderr.out rm: cannot remove `vgcore.pid*': No such file or directory (cleanup operation failed: rm vgcore.pid*) pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 204 tests, 2 stderr failures, 0 stdout failures ================= memcheck/tests/scalar (stderr) memcheck/tests/scalar_supp (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-03-06 03:22:09
|
Nightly build on audi ( Red Hat 9 ) started at 2005-03-06 03:15:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow fpu_lazy_eflags: valgrind ./fpu_lazy_eflags insn_basic: valgrind ./insn_basic insn_cmov: valgrind ./insn_cmov insn_fpu: valgrind ./insn_fpu insn_mmx: valgrind ./insn_mmx insn_mmxext: valgrind ./insn_mmxext insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int rm: cannot remove `vgcore.pid*': No such file or directory (cleanup operation failed: rm vgcore.pid*) pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 203 tests, 0 stderr failures, 0 stdout failures ================= |
|
From: Tom H. <th...@cy...> - 2005-03-06 03:16:24
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2005-03-06 03:10:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_fpu: valgrind ./insn_fpu insn_mmx: valgrind ./insn_mmx insn_mmxext: valgrind ./insn_mmxext insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int rm: cannot remove `vgcore.pid*': No such file or directory (cleanup operation failed: rm vgcore.pid*) pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 202 tests, 2 stderr failures, 0 stdout failures ================= memcheck/tests/pth_once (stderr) memcheck/tests/threadederrno (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-03-06 03:15:27
|
Nightly build on standard ( Red Hat 7.2 ) started at 2005-03-06 03:00:01 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int rm: cannot remove `vgcore.pid*': No such file or directory (cleanup operation failed: rm vgcore.pid*) pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 202 tests, 5 stderr failures, 0 stdout failures ================= memcheck/tests/leak-tree (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/vgtest_ume (stderr) addrcheck/tests/leak-tree (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-03-06 03:11:31
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2005-03-06 03:05:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow == 202 tests, 17 stderr failures, 0 stdout failures ================= memcheck/tests/addressable (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/vgtest_ume (stderr) addrcheck/tests/leak-0 (stderr) addrcheck/tests/leak-cycle (stderr) addrcheck/tests/leak-regroot (stderr) addrcheck/tests/leak-tree (stderr) massif/tests/toobig-allocs (stderr) massif/tests/true_html (stderr) massif/tests/true_text (stderr) make: *** [regtest] Error 1 |
|
From: Robert W. <rj...@du...> - 2005-03-06 03:02:19
|
There's a manual page now. It is installed, but not yet included in the .spec file. Jeremy: can you put it into the .spec file: I'm not sure how manual pages are normally handled in there. I'd appreciate feedback on the contents. Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Robert W. <rj...@du...> - 2005-03-06 03:00:38
|
CVS commit by rjwalsh: Valgrind manual page. This should be mostly done now. M +285 -94 valgrind.1 1.3 --- valgrind/docs/valgrind.1 #1.2:1.3 @@ -12,5 +12,5 @@ .SH DESCRIPTION -\fIvalgrind\fP is a flexible program for debugging and profiling Linux-x86 +\fBvalgrind\fP is a flexible program for debugging and profiling Linux-x86 executables. It consists of a core, which provides a synthetic x86 CPU in software, and a series of "tools", each of which is a debugging or @@ -20,5 +20,55 @@ .PP This manual page covers only basic usage and options. Please see the -html documentation for more comprehensive information. +HTML documentation for more comprehensive information. + +.SH INVOCATION +\fBvalgrind\fP is typically invoked as follows: + + valgrind program args + +This runs \fBprogram\fP (with arguments \fBargs\fP) under valgrind using +the \fBmemcheck\fP tool. To use a different tool, use the \fB--tool\fP +option: + + valgrind --tool=addrcheck program args + +The following tools are available: + +.RS +.TP +.B +- addrcheck +\fBaddrcheck\fP is similar to memcheck, but does not perform the same +granularity of memory checking. +.TP +.B +- cachegrind +\fBcachegrind\fP is a cache simulator. +." .TP +." .B +." - helgrind +." \fBhelgrind\fP spots potential race conditions in your program. +.TP +.B +- lackey +\fBlackey\fP is a sample tool that can be used as a template for +generating your own tools. After the program terminates, it prints out +some basic statistics about the program execution. +.TP +.B +- massif +\fBmassif\fP is a heap profiler. It measures how much heap memory your +program uses. +.TP +.B +- memcheck +\fBmemcheck\fP is a fine-grained memory checker. +.TP +.B +- none +\fBnone\fP performs no function - it simply runs the program under +\fBvalgrind\fP. This is typically used for debugging and benchmarking +\fBvalgrind\fP. +.RE .SH COMMON CORE OPTIONS @@ -27,5 +77,5 @@ .B --db-attach=<yes|no> [default: no] -When enabled, \fIvalgrind\fP will pause after every error shown and +When enabled, \fBvalgrind\fP will pause after every error shown and print the line: @@ -39,10 +89,10 @@ .RS -Pressing Ret, or N Ret or n Ret, causes \fIvalgrind\fP not to start a +Pressing Ret, or N Ret or n Ret, causes \fBvalgrind\fP not to start a debugger for this error. .PP -Pressing Y Ret or y Ret causes \fIvalgrind\fP to start the debugger -(specified by the \fI--db-command\fP option) for the program at this +Pressing Y Ret or y Ret causes \fBvalgrind\fP to start the debugger +(specified by the \fB--db-command\fP option) for the program at this point. When you have finished with the debugger, quit from it, and the program will continue. Trying to continue from inside the debugger @@ -50,10 +100,10 @@ .PP -Pressing C Ret or c Ret causes \fIvalgrind\fI not to start the debugger -and \fIvalgrind\fP will not ask again. +Pressing C Ret or c Ret causes \fBvalgrind\fP not to start the debugger +and \fBvalgrind\fP will not ask again. .PP --db-attach=yes conflicts with --trace-children=yes. You can't use them -together. \fIvalgrind\fP refuses to start up in this situation. 1 May +together. \fBvalgrind\fP refuses to start up in this situation. 1 May 2002: this is a historical relic which could be easily fixed if it gets in your way. Mail me and complain if this is a problem for you. @@ -69,11 +119,11 @@ Specify the debugger to use with the --db-attach command. The default debugger is gdb. This option is a template that is expanded by -\fIvalgrind\fP at runtime. \fI%f\fP is replaced with the executable's -file name and \fI%p\fP is replaced by the process ID of the executable. +\fBvalgrind\fP at runtime. \fB%f\fP is replaced with the executable's +file name and \fB%p\fP is replaced by the process ID of the executable. .TP .B --error-limit=<yes|no> [default: yes] -When enabled, \fIvalgrind\fP stops reporting errors after 30000 in total, +When enabled, \fBvalgrind\fP stops reporting errors after 30000 in total, or 300 different ones, have been seen. This is to stop the error tracking machinery from becoming a huge performance overhead in programs with @@ -83,5 +133,5 @@ --gen-suppressions=<yes|no> [default: no] -When enabled, \fIvalgrind\fP will pause after every error shown and +When enabled, \fBvalgrind\fP will pause after every error shown and print the line: @@ -104,5 +154,5 @@ .P Pressing C Ret or c Ret will cause no suppression to be printed and -\fIvalgrind\fP will not ask again. +\fBvalgrind\fP will not ask again. .RE @@ -110,17 +160,16 @@ .B -h --help -Show help for all \fIoptions\fP, both for the core and for the selected -tool. +Show help for all options, both for the core and for the selected tool. .TP .B --help-debug -Show help for all \fIoptions\fP, both for the core and for the selected -tool, including options for debugging \fIvalgrind\fP. +Show help for all options, both for the core and for the selected tool, +including options for debugging \fBvalgrind\fP. .TP .B --log-file=<filename> -Specifies that \fIvalgrind\fP should send all of its messages to the +Specifies that \fBvalgrind\fP should send all of its messages to the specified file. In fact, the file name used is created by concatenating the text filename, ".pid" and the process ID, so as to create a file @@ -130,5 +179,5 @@ .B --num-callers=<number> [default=12] -By default, \fIvalgrind\fP shows four levels of function call names to +By default, \fBvalgrind\fP shows 12 levels of function call names to help you identify program locations. You can change that number with this option. This can help in determining the program's location in @@ -141,5 +190,5 @@ .PP The maximum value for this is 50. Note that higher settings will make -\fIvalgrind\fP run a bit more slowly and take a bit more memory, but +\fBvalgrind\fP run a bit more slowly and take a bit more memory, but can be useful when working with programs with deeply-nested call chains. .RE @@ -153,5 +202,5 @@ .TP .B ---suppressions=<filename> [default: $PREFIX/lib/\fIvalgrind\fP/default.supp] +--suppressions=<filename> [default: $PREFIX/lib/\fBvalgrind\fP/default.supp] Specifies an extra file from which to read descriptions of errors to suppress. You may specify up to 10 additional suppression files. @@ -160,76 +209,216 @@ .B --tool=<toolname> [default: memcheck] -Specify which tool to use. The default tool is memcheck. The following -tools are available: +Specify which tool to use. The default tool is memcheck. -.RS .TP .B -- addrcheck -\fIaddrcheck\fP is similar to memcheck, but does not perform the same -granularity of memory checking. +--trace-children=<yes|no> [default: no] +When enabled, \fBvalgrind\fP will trace into child processes. This is +confusing and usually not what you want, so is disabled by default. + .TP .B -- cachegrind -\fIcachegrind\fP is a cache simulator. +--track-fds=<yes|no> [default: no] +Track file descriptor creation and deletion and produce a summary at the +end of the program execution of file descriptors that are still in use. + .TP .B -- helgrind -\fIhelgrind\fP spots potential race conditions in your program. +-v --verbose +Be more verbose. Gives extra information on various aspects of your +program, such as: the shared objects loaded, the suppressions used, +the progress of the instrumentation and execution engines, and warnings +about unusual behaviour. Repeating the flag increases the verbosity level. + .TP .B -- lackey -\fIlackey\fP is a sample tool that can be used as a template for -generating your own tools. +--version +Show the version number of the \fBvalgrind\fP core. Tools can have +their own version numbers. There is a scheme in place to ensure that +tools only execute when the core version is one they are known to work +with. This was done to minimise the chances of strange problems arising +from tool-vs-core version incompatibilities. + +.SH ADDRCHECK OPTIONS + .TP .B -- massif -\fImassif\fP is a heap profiler. It measures how much heap memory your -program uses. +--freelist-vol=<number> [default: 1000000] +When the client program releases memory using free (in C) or delete +(C++), that memory is not immediately made available for re-allocation. +Instead it is marked inaccessible and placed in a queue of freed blocks. +The purpose is to delay the point at which freed-up memory comes back +into circulation. This increases the chance that \fBaddrcheck\fP will +be able to detect invalid accesses to blocks for some significant period +of time after they have been freed. + +.RS +This flag specifies the maximum total size, in bytes, of the blocks in +the queue. The default value is one million bytes. Increasing this +increases the total amount of memory used by \fBaddrcheck\fP but may +detect invalid uses of freed blocks which would otherwise go undetected. +.RE + .TP .B -- memcheck -\fImemcheck\fP is a fine-grained memory checker. +--leak-check=<yes|no|summary|full> [default: summary] +Enables full, summary or no leak checking. When full (\fBfull\fP or +\fByes\fP options) checking is performed, details on all leaked blocks +are printed after the program finishes executing. When summary checking +is enabled, a summary of all leaked memory is printed. When no leak +checking is performed, no leaked memory details are produced. Disabling +leak checking can speed up your program execution. + .TP .B -- none -\fInone\fP performs no function - it simply runs the program under -\fIvalgrind\fP. +--leak-resolution=<low|med|high> [default: low] +When doing leak checking, determines how willing \fBaddrcheck\fP is to +consider different backtraces to be the same. When set to \fBlow\fP, +the default, only the first two entries need match. When \fBmed\fP, +four entries have to match. When \fBhigh\fP, all entries need to match. + +.TP +.B +--partial-loads-ok=<yes|no> [default: yes] +Controls how \fBaddrcheck\fP handles word (4-byte) loads from addresses +for which some bytes are addressible and others are not. When enabled, +such loads do not elicit an address error. Instead, \fBaddrcheck\fP +considers the bytes corresponding to the illegal addresses as undefined, +and those corresponding to legal addresses are considered defined. + +.RS +When disabled, loads from partially invalid addresses are treated the +same as loads from completely invalid addresses: an illegal-address error +is issued, and the \fBaddrcheck\fP considers all bytes as invalid data. .RE .TP .B ---trace-children=<yes|no> [default: no] -When enabled, \fIvalgrind\fP will trace into child processes. This is -confusing and usually not what you want, so is disabled by default. +--show-reachable=<yes|no> [default: no] +When performing full leak checking, print out details of blocks that are +leaked but still reachable. For details of what a reachable block is, +see the HTML documentation. .TP .B ---track-fds=<yes|no> [default: no] -Track file descriptor creation and deletion and produce a summary at the -end of the program execution of file descriptors that are still in use. +--workaround-gcc296-bugs=<yes|no> [default: no] +When enabled, assume that reads and writes some small distance below +the stack pointer \fB%esp\fP are due to bugs in gcc 2.96, and does not +report them. The "small distance" is 256 bytes by default. Note that gcc +2.96 is the default compiler on some older Linux distributions (RedHat +7.X, Mandrake) and so you may well need to use this flag. Do not use +it if you do not have to, as it can cause real errors to be overlooked. +Another option is to use a gcc/g++ which does not generate accesses below +the stack pointer. 2.95.3 seems to be a good choice in this respect. + +.SH MEMCHECK OPTIONS +\fBmemcheck\fP understands the same options as \fBaddrcheck\fP, along +with the following options: .TP .B --v --verbose -Be more verbose. Gives extra information on various aspects of your -program, such as: the shared objects loaded, the suppressions used, -the progress of the instrumentation and execution engines, and warnings -about unusual behaviour. Repeating the flag increases the verbosity level. +--avoid-strlen-errors=<yes|no> [default: yes] +Enable or disable a heuristic for dealing with highly-optimized versions +of \fBstrlen\fP. These versions of \fBstrlen\fP can cause spurious +errors to be reported by \fBmemcheck\fP, so it's usually a good idea to +leave this enabled. .TP .B ---version -Show the version number of the \fIvalgrind\fP core. Tools can have -their own version numbers. There is a scheme in place to ensure that -tools only execute when the core version is one they are known to work -with. This was done to minimise the chances of strange problems arising -from tool-vs-core version incompatibilities. +--cleanup=<yes|no> [default: yes] +\fBThis is a flag to help debug valgrind itself. It is of no use to +end-users\fP. When enabled, various improvments are applied to the +post-instrumented intermediate code, aimed at removing redundant value +checks. + +.SH CACHEGRIND OPTIONS + +.TP +.B +--D1=<size>,<associativity>,<line size> +Specify the size, associativity and line size of the level 1 data cache. +All values are measured in bytes. If this options is not specified, +the system value (as retrieved by the \fBCPUID\fP instruction) is used. + +.TP +.B +--I1=<size>,<associativity>,<line size> +Specify the size, associativity and line size of the level 1 instruction +cache. All values are measured in bytes. If this options is not +specified, the system value (as retrieved by the \fBCPUID\fP instruction) +is used. + +.TP +.B +--L2=<size>,<associativity>,<line size> +Specify the size, associativity and line size of the level 2 cache. +All values are measured in bytes. If this options is not specified, +the system value (as retrieved by the \fBCPUID\fP instruction) is used. + +.SH MASSIF OPTIONS + +.TP +.B +--alloc-fn=<name> +Specify a function that allocates memory. This is useful for functions +that are wrappers to \fBmalloc()\fP, which can fill up the context +information uselessly (and give very uninformative bands on the graph). +Functions specified will be ignored in contexts, i.e. treated as though +they were \fBmalloc()\fP. This option can be specified multiple times +on the command line, to name multiple functions. + +.TP +.B +--depth=<number> [default: 3] +Depth of call chains to present in the detailed heap information. +Increasing it will give more information, but \fBmassif\fP will run the +program more slowly, using more memory, and produce a bigger \fB.txt\fP +or \fB.hp\fP file. + +.TP +.B +--format=<text|html> [default: text] +Produce the detailed heap information in text or HTML format. The file +suffix used will be either \fB.txt\fP or \fB.html\fP. + +.TP +.B +--heap=<yes|no> [default: yes] +When enabled, profile heap usage in detail. Without it, the \fB.txt\fP +or \fB.html\fP file will be very short. + +.TP +.B +--heap-admin=<number> [default: 8] +The number of admin bytes per block to use. This can only be an +estimate of the average, since it may vary. The allocator used +by \fBglibc\fP requires somewhere between 4 to 15 bytes per block, +depending on various factors. It also requires admin space for freed +blocks, although \fBmassif\fP does not count this. + +.TP +.B +--stacks=<yes|no> [default: yes] +When enabled, include stack(s) in the profile. Threaded programs can +have multiple stacks. + +.SH HELGRIND OPTIONS + +.TP +.B +--private-stacks=<yes|no> [default: no] +Assume thread stacks are used privately. + +.TP +.B +--show-last-access=<yes|some|no> [default: no] +Show location of last word access on error. .SH LESS FREQUENTLY USED CORE OPTIONS + .TP .B --alignment=<number> [default: 8] -By default \fIvalgrind\fP's malloc, realloc, etc, return 8-byte aligned +By default \fBvalgrind\fP's malloc, realloc, etc, return 8-byte aligned addresses. These are suitable for any accesses on x86 processors. Some programs might however assume that malloc et al return 16- or more @@ -259,18 +448,18 @@ .B --command-line-only=<yes|no> [default: no] -Normally, \fIvalgrind\fP will look for command-line options in the +Normally, \fBvalgrind\fP will look for command-line options in the following locations: .RS .TP -- The \fIvalgrind\fP command line +- The \fBvalgrind\fP command line .TP -- The \fI\.valgrindrc\fP file in the invocation directory +- The \fB\.valgrindrc\fP file in the invocation directory .TP -- The \fI\.valgrindrc\fP file in users home directory +- The \fB\.valgrindrc\fP file in users home directory .TP -- The \fI$VALGRIND_OPTS\fP environment variable +- The \fB$VALGRIND_OPTS\fP environment variable .P -When this option is enabled, \fIvalgrind\fP will only look at the command +When this option is enabled, \fBvalgrind\fP will only look at the command line for options. .RE @@ -280,5 +469,5 @@ --demangle=<yes|no> [default: yes] Enable or disable automatic demangling (decoding) of C++ names. Enabled by -default. When enabled, \fIvalgrind\fP will attempt to translate encoded +default. When enabled, \fBvalgrind\fP will attempt to translate encoded C++ procedure names back to something approaching the original. The demangler handles symbols mangled by g++ versions 2.X and 3.X. @@ -288,5 +477,5 @@ --dump-error=<number> After the program has exited, show gory details of the translation of -the basic block containing the \fI<number>\fP'th error context. When +the basic block containing the \fB<number>\fP'th error context. When used with --single-step=yes, can show the exact x86 instruction causing an error. This is all fairly dodgy and doesn't work at all if threads @@ -297,6 +486,6 @@ --exec=<filename> Specify the executable to run. If this is specified, it takes precedence -over the \fIyour-program\fP executable from the command-line. If this is -not specified, \fIvalgrind\fP searches the path for the \fIyour-program\fP +over the \fByour-program\fP executable from the command-line. If this is +not specified, \fBvalgrind\fP searches the path for the \fByour-program\fP executable, just like a regular shell would. @@ -305,10 +494,10 @@ --input-fd=<number> [default: 0, stdin] Specify the file descriptor to use for reading input from the user. This -is used whenever \fIvalgrind\fP needs to prompt the user for a decision. +is used whenever \fBvalgrind\fP needs to prompt the user for a decision. .TP .B --log-fd=<number> [default: 2, stderr] -Specifies that \fIvalgrind\fP should send all of its messages to +Specifies that \fBvalgrind\fP should send all of its messages to the specified file descriptor. The default, 2, is the standard error channel (stderr). Note that this may interfere with the client's own @@ -318,10 +507,10 @@ .B --log-socket=<ip-address:port-number> -Specifies that \fIvalgrind\fP should send all of its messages to the +Specifies that \fBvalgrind\fP should send all of its messages to the specified port at the specified IP address. The port may be omitted, in which case port 1500 is used. If a connection cannot be made to -the specified socket, \fIvalgrind\fP falls back to writing output to +the specified socket, \fBvalgrind\fP falls back to writing output to the standard error (stderr). This option is intended to be used in -conjunction with the \fIvalgrind-listener\fP program. For further details, +conjunction with the \fBvalgrind-listener\fP program. For further details, see section 2.3 of the user manual. @@ -338,5 +527,5 @@ When enabled, enforces client address space limits. If this option is disabled, the client program has full and unfettered access to the part -of the address space used internally by \fIvalgrind\fP. This can cause +of the address space used internally by \fBvalgrind\fP. This can cause unexplained crashes and false error reports, so it is best left enabled. @@ -353,5 +542,5 @@ .PP The glibc authors realised that this behaviour causes leak checkers, -such as \fIvalgrind\fP, to falsely report leaks in glibc, when a leak +such as \fBvalgrind\fP, to falsely report leaks in glibc, when a leak check is done at exit. In order to avoid this, they provided a routine called __libc_freeres specifically to make glibc release all memory it @@ -363,5 +552,5 @@ buggy to cause segmentation faults. This is particularly noticeable on Red Hat 7.1. So this flag is provided in order to inhibit the run of -__libc_freeres. If your program seems to run fine on \fIvalgrind\fP, but +__libc_freeres. If your program seems to run fine on \fBvalgrind\fP, but segfaults at exit, you may find that --run-libc-freeres=no fixes that, although at the cost of possibly falsely reporting space leaks in libc.so. @@ -372,6 +561,6 @@ --show-below-main=<yes|no> [default: no] When enabled, this option causes full stack backtraces to be emited, -including the part before \fImain\fP in your program (subject to the -\fI--num-callers\fP option.) When disabled, only the part of the stack +including the part before \fBmain\fP in your program (subject to the +\fB--num-callers\fP option.) When disabled, only the part of the stack backtrace up to and including main is printed. @@ -382,10 +571,10 @@ code. When disabled, translation is done on a per-basic-block basis, giving much better translations. This is needed when running -\fIvalgrind\fP under \fIvalgrind\fP. +\fBvalgrind\fP under \fBvalgrind\fP. .TP .B --sloppy-malloc=<yes|no> [default: no] -When enabled, \fIvalgrind\fP rounds all memory allocation request sizes +When enabled, \fBvalgrind\fP rounds all memory allocation request sizes up to 4 bytes. @@ -398,5 +587,5 @@ .B --weird-hacks=hack1,hack2,\.\.\. -Pass miscellaneous hints to \fIvalgrind\fP which slightly modify the +Pass miscellaneous hints to \fBvalgrind\fP which slightly modify the simulated behaviour in nonstandard or dangerous ways, possibly to help the simulation of strange features. By default no hacks are enabled. Use @@ -407,13 +596,13 @@ .B - lax-ioctls -If \fIvalgrind\fP encounters an \fIioctl\fP that it doesn't understand, +If \fBvalgrind\fP encounters an \fBioctl\fP that it doesn't understand, it normally prints a warning message before continuing. Specifying the -lax-ioctls hack tells \fIvalgrind\fP to be very lax about ioctl handling +lax-ioctls hack tells \fBvalgrind\fP to be very lax about ioctl handling and assume that unknown ioctls just behave correctly. .TP .B - ioctl-mmap -Tell \fIvalgrind\fP to search for new memory mappings after an unknown -\fIioctl\fP call. +Tell \fBvalgrind\fP to search for new memory mappings after an unknown +\fBioctl\fP call. .RE @@ -423,7 +612,7 @@ .B --profile=<yes|no> [default: no] -When enabled, does crude internal profiling of \fIvalgrind\fP itself. This +When enabled, does crude internal profiling of \fBvalgrind\fP itself. This is not for profiling your programs. Rather it is to allow the developers -to assess where \fIvalgrind\fP is spending its time. The tools must be +to assess where \fBvalgrind\fP is spending its time. The tools must be built for profiling for this to work. @@ -432,5 +621,5 @@ --sanity-level=<number> [default: 1] Set the level of sanity checking to perform. This is used for debugging -\fIvalgrind\fP. Setting this to 2 or higher can cause more internal +\fBvalgrind\fP. Setting this to 2 or higher can cause more internal sanity checks to be performed, but can slow your program down appreciably. Setting this to 0 disables sanity checks. @@ -439,5 +628,5 @@ .B --trace-codegen=<bitmask> -Produce lots of output showing exactly how \fIvalgrind\fP is translating +Produce lots of output showing exactly how \fBvalgrind\fP is translating each basic block. The argument to this option is a 5-bit wide bitmask. Each bit refers to a specific feature to trace. If the bit is 1, the @@ -489,7 +678,9 @@ .SH SEE ALSO -/usr/share/doc/\fIvalgrind\fP/html/manual.html +/usr/share/doc/\fBvalgrind\fP/html/manual.html + .SH AUTHOR This manpage has been written by Andres Roldan <ar...@de...> for the Debian Project, but can be used for any other distribution. -Updated by Robert Walsh <rj...@du...> for the 2.4.0 release. +Updated, rearranged and expanded by Robert Walsh <rj...@du...> +for the 2.4.0 release. |
|
From: Robert W. <rj...@du...> - 2005-03-06 02:25:04
|
CVS commit by rjwalsh:
Fix an HTML error.
M +1 -1 mc_main.html 1.17
--- valgrind/memcheck/docs/mc_main.html #1.16:1.17
@@ -85,5 +85,5 @@
</li><br><p>
- <li><code>--freelist-vol=<number></code> [default: 1000000]
+ <li><code>--freelist-vol=<number></code> [default: 1000000]
<p>When the client program releases memory using free (in C) or
delete (C++), that memory is not immediately made available for
|
|
From: Robert W. <rj...@du...> - 2005-03-06 02:08:19
|
CVS commit by rjwalsh: More work-in-progress on the manual page. All the core options are now covered. M +349 -172 valgrind.1 1.2 --- valgrind/docs/valgrind.1 #1.1:1.2 @@ -1,11 +1,14 @@ .TH VALGRIND "1" "" "" + .SH NAME \fBvalgrind \fP- a memory debugger for x86-linux + .SH SYNOPSIS .nf .fam C -\fIvalgrind\fP [\fIvalgrind\fP \fIoptions\fP] \fIyour-prog\fP [\fIyour-prog\fP \fIoptions\fP] +\fIvalgrind\fP [\fIvalgrind\fP \fIoptions\fP] \fIyour-program\fP [\fIyour-program\fP \fIoptions\fP] .fam T .fi + .SH DESCRIPTION \fIvalgrind\fP is a flexible program for debugging and profiling Linux-x86 @@ -14,35 +17,17 @@ profiling tool. The architecture is modular, so that new tools can be created easily and without disturbing the existing structure. + .PP This manual page covers only basic usage and options. Please see the -html documentation for more comprehensive usage. -.SH CORE OPTIONS -.TP -.B ---alignment=<number> [default: 8] -By default \fIvalgrind\fP's malloc, realloc, etc, return 8-byte aligned -addresses. These are suitable for any accesses on x86 processors. Some -programs might however assume that malloc et al return 16- or more -aligned memory. These programs are broken and should be fixed, but if -this is impossible for whatever reason the alignment can be increased -using this parameter. The supplied value must be between 8 and 4096 -inclusive, and must be a power of two. -.TP -.B ---branchpred -XXX -.TP -.B ---chain-bb -XXX -.TP -.B ---command-line-only -XXX +html documentation for more comprehensive information. + +.SH COMMON CORE OPTIONS + .TP .B --db-attach=<yes|no> [default: no] -When enabled, Valgrind will pause after every error shown, and print -the line +When enabled, \fIvalgrind\fP will pause after every error shown and +print the line: + .PP .nf @@ -52,48 +37,41 @@ .fam T .fi + .RS -Pressing Ret, or N Ret or n Ret, causes Valgrind not to start a debugger -for this error. +Pressing Ret, or N Ret or n Ret, causes \fIvalgrind\fP not to start a +debugger for this error. + .PP -Y Ret or y Ret causes Valgrind to start the debugger (specified by the -\fI--db-command\fP option) for the program at this point. When you -have finished with the debugger, quit from it, and the program will -continue. Trying to continue from inside the debugger doesn't work. +Pressing Y Ret or y Ret causes \fIvalgrind\fP to start the debugger +(specified by the \fI--db-command\fP option) for the program at this +point. When you have finished with the debugger, quit from it, and +the program will continue. Trying to continue from inside the debugger +doesn't work. + .PP -C Ret or c Ret causes Valgrind not to start the debugger, and not to -ask again. +Pressing C Ret or c Ret causes \fIvalgrind\fI not to start the debugger +and \fIvalgrind\fP will not ask again. + .PP --db-attach=yes conflicts with --trace-children=yes. You can't use them -together. Valgrind refuses to start up in this situation. 1 May 2002: -this is a historical relic which could be easily fixed if it gets in -your way. Mail me and complain if this is a problem for you. +together. \fIvalgrind\fP refuses to start up in this situation. 1 May +2002: this is a historical relic which could be easily fixed if it gets +in your way. Mail me and complain if this is a problem for you. + .PP Nov 2002: if you're sending output to a logfile or to a network socket, I guess this option doesn't make any sense. Caveat emptor. .RE + .TP .B --db-command=<command> [default: gdb -nw %f %p] -Specify the debugger to use with the --db-attach command. The default -debugger is gdb. This option is a template that is expanded by valgrind -at runtime. \fI%f\fP is replaced with the executable's file name and -\fI%p\fP is replaced by the process ID of the executable. -.TP -.B ---demangle=<yes|no> [default: yes] -Disable/enable automatic demangling (decoding) of C++ names. Enabled by -default. When enabled, Valgrind will attempt to translate encoded C++ -procedure names back to something approaching the original. The demangler -handles symbols mangled by g++ versions 2.X and 3.X. -.TP -.B ---dump-error=<number> [default: inactive] -After the program has exited, show gory details of the translation of -the basic block containing the <number>'th error context. When used -with --single-step=yes, can show the exact x86 instruction causing -an error. This is all fairly dodgy and doesn't work at all if threads -are involved. +Specify the debugger to use with the --db-attach command. The +default debugger is gdb. This option is a template that is expanded by +\fIvalgrind\fP at runtime. \fI%f\fP is replaced with the executable's +file name and \fI%p\fP is replaced by the process ID of the executable. .TP .B + --error-limit=<yes|no> [default: yes] When enabled, \fIvalgrind\fP stops reporting errors after 30000 in total, @@ -103,10 +81,30 @@ .TP .B ---exec -XXX -.TP -.B ---gen-suppressions -Automatically generate suppressions. + +--gen-suppressions=<yes|no> [default: no] +When enabled, \fIvalgrind\fP will pause after every error shown and +print the line: + +.PP +.nf +.fam C + ---- Print suppression ? --- [Return/N/n/Y/y/C/c] ---- + +.fam T +.fi + +.RS +Pressing Y Ret or y Ret will cause a suppression for this error to be +printed. This suppression can be cut-and-paste into a custom suppressions +file and used to suppress this error in subsequent runs. + +.P +Pressing Ret or n Ret or N Ret will cause no suppression to be printed. + +.P +Pressing C Ret or c Ret will cause no suppression to be printed and +\fIvalgrind\fP will not ask again. +.RE + .TP .B @@ -114,4 +112,5 @@ Show help for all \fIoptions\fP, both for the core and for the selected tool. + .TP .B @@ -119,34 +118,17 @@ Show help for all \fIoptions\fP, both for the core and for the selected tool, including options for debugging \fIvalgrind\fP. -.TP -.B ---input-fd -XXX -.TP -.B ---log-fd=<number> [default: 2, stderr] -Specifies that Valgrind should send all of its messages to the specified -file descriptor. The default, 2, is the standard error channel (stderr). -Note that this may interfere with the client's own use of stderr. + .TP .B --log-file=<filename> -Specifies that Valgrind should send all of its messages to the specified -file. In fact, the file name used is created by concatenating the text -filename, ".pid" and the process ID, so as to create a file per process. -The specified file name may not be the empty string. -.TP -.B ---log-socket=<ip-address:port-number> -Specifies that Valgrind should send all of its messages to the specified -port at the specified IP address. The port may be omitted, in which -case port 1500 is used. If a connection cannot be made to the specified -socket, \fIvalgrind\fP falls back to writing output to the standard error -(stderr). This option is intended to be used in conjunction with the -\fIvalgrind\fP-listener program. For further details, see section 2.3. +Specifies that \fIvalgrind\fP should send all of its messages to the +specified file. In fact, the file name used is created by concatenating +the text filename, ".pid" and the process ID, so as to create a file +per process. The specified file name may not be the empty string. + .TP .B --num-callers=<number> [default=12] -By default, Valgrind shows four levels of function call names to +By default, \fIvalgrind\fP shows four levels of function call names to help you identify program locations. You can change that number with this option. This can help in determining the program's location in @@ -155,32 +137,208 @@ and that of its two immediate callers). So this doesn't affect the total number of errors reported. + .RS .PP The maximum value for this is 50. Note that higher settings will make -Valgrind run a bit more slowly and take a bit more memory, but can be -useful when working with programs with deeply-nested call chains. +\fIvalgrind\fP run a bit more slowly and take a bit more memory, but +can be useful when working with programs with deeply-nested call chains. .RE + .TP .B ---optimise=<yes|no> [default: yes] -When enabled, various improvements are applied to the intermediate code, -mainly aimed at allowing the simulated CPU's registers to be cached in -the real CPU's registers over several simulated instructions. +-q --quiet +Run silently, and only print error messages. Useful if you are running +regression tests or have some other automated test machinery. + .TP .B ---pointercheck -XXX +--suppressions=<filename> [default: $PREFIX/lib/\fIvalgrind\fP/default.supp] +Specifies an extra file from which to read descriptions of errors to +suppress. You may specify up to 10 additional suppression files. + .TP .B ---profile=<yes|no> [default: no] -When enabled, does crude internal profiling of \fIvalgrind\fP itself. This -is not for profiling your programs. Rather it is to allow the developers -to assess where \fIvalgrind\fP is spending its time. The tools must be -built for profiling for this to work. +--tool=<toolname> [default: memcheck] +Specify which tool to use. The default tool is memcheck. The following +tools are available: + +.RS .TP .B --q --quiet -Run silently, and only print error messages. Useful if you are running -regression tests or have some other automated test machinery. +- addrcheck +\fIaddrcheck\fP is similar to memcheck, but does not perform the same +granularity of memory checking. +.TP +.B +- cachegrind +\fIcachegrind\fP is a cache simulator. +.TP +.B +- helgrind +\fIhelgrind\fP spots potential race conditions in your program. +.TP +.B +- lackey +\fIlackey\fP is a sample tool that can be used as a template for +generating your own tools. +.TP +.B +- massif +\fImassif\fP is a heap profiler. It measures how much heap memory your +program uses. +.TP +.B +- memcheck +\fImemcheck\fP is a fine-grained memory checker. +.TP +.B +- none +\fInone\fP performs no function - it simply runs the program under +\fIvalgrind\fP. +.RE + +.TP +.B +--trace-children=<yes|no> [default: no] +When enabled, \fIvalgrind\fP will trace into child processes. This is +confusing and usually not what you want, so is disabled by default. + +.TP +.B +--track-fds=<yes|no> [default: no] +Track file descriptor creation and deletion and produce a summary at the +end of the program execution of file descriptors that are still in use. + +.TP +.B +-v --verbose +Be more verbose. Gives extra information on various aspects of your +program, such as: the shared objects loaded, the suppressions used, +the progress of the instrumentation and execution engines, and warnings +about unusual behaviour. Repeating the flag increases the verbosity level. + +.TP +.B +--version +Show the version number of the \fIvalgrind\fP core. Tools can have +their own version numbers. There is a scheme in place to ensure that +tools only execute when the core version is one they are known to work +with. This was done to minimise the chances of strange problems arising +from tool-vs-core version incompatibilities. + +.SH LESS FREQUENTLY USED CORE OPTIONS +.TP +.B +--alignment=<number> [default: 8] +By default \fIvalgrind\fP's malloc, realloc, etc, return 8-byte aligned +addresses. These are suitable for any accesses on x86 processors. Some +programs might however assume that malloc et al return 16- or more +aligned memory. These programs are broken and should be fixed, but if +this is impossible for whatever reason the alignment can be increased +using this parameter. The supplied value must be between 8 and 4096 +inclusive, and must be a power of two. + +.TP +.B +--branchpred=<yes|no> [default: no] +This option enables the generation of static branch prediction hints. +In theory this allows the real CPU to do a better job of running the +generated code, but in practice it makes almost no measurable difference. +It may have a large effect on some x86 implementations. + +.TP +.B +--chain-bb=<yes|no> [default: yes] +Enables basic-block chaining. If basic-block chaining is disabled, +the synthetic CPU returns to the scheduler after interpreting each basic +block. With basic block chaining enabled, it can immediately proceed to +the next basic block. This almost always results in a performance gain, +so it is enabled by default. + +.TP +.B +--command-line-only=<yes|no> [default: no] +Normally, \fIvalgrind\fP will look for command-line options in the +following locations: +.RS +.TP +- The \fIvalgrind\fP command line +.TP +- The \fI\.valgrindrc\fP file in the invocation directory +.TP +- The \fI\.valgrindrc\fP file in users home directory +.TP +- The \fI$VALGRIND_OPTS\fP environment variable +.P + +When this option is enabled, \fIvalgrind\fP will only look at the command +line for options. +.RE + +.TP +.B +--demangle=<yes|no> [default: yes] +Enable or disable automatic demangling (decoding) of C++ names. Enabled by +default. When enabled, \fIvalgrind\fP will attempt to translate encoded +C++ procedure names back to something approaching the original. The +demangler handles symbols mangled by g++ versions 2.X and 3.X. + +.TP +.B +--dump-error=<number> +After the program has exited, show gory details of the translation of +the basic block containing the \fI<number>\fP'th error context. When +used with --single-step=yes, can show the exact x86 instruction causing +an error. This is all fairly dodgy and doesn't work at all if threads +are involved. + +.TP +.B +--exec=<filename> +Specify the executable to run. If this is specified, it takes precedence +over the \fIyour-program\fP executable from the command-line. If this is +not specified, \fIvalgrind\fP searches the path for the \fIyour-program\fP +executable, just like a regular shell would. + +.TP +.B +--input-fd=<number> [default: 0, stdin] +Specify the file descriptor to use for reading input from the user. This +is used whenever \fIvalgrind\fP needs to prompt the user for a decision. + +.TP +.B +--log-fd=<number> [default: 2, stderr] +Specifies that \fIvalgrind\fP should send all of its messages to +the specified file descriptor. The default, 2, is the standard error +channel (stderr). Note that this may interfere with the client's own +use of stderr. + +.TP +.B +--log-socket=<ip-address:port-number> +Specifies that \fIvalgrind\fP should send all of its messages to the +specified port at the specified IP address. The port may be omitted, +in which case port 1500 is used. If a connection cannot be made to +the specified socket, \fIvalgrind\fP falls back to writing output to +the standard error (stderr). This option is intended to be used in +conjunction with the \fIvalgrind-listener\fP program. For further details, +see section 2.3 of the user manual. + +.TP +.B +--optimise=<yes|no> [default: yes] +When enabled, various improvements are applied to the intermediate code, +mainly aimed at allowing the simulated CPU's registers to be cached in +the real CPU's registers over several simulated instructions. + +.TP +.B +--pointercheck=<yes|no> [default: yes] +When enabled, enforces client address space limits. If this option is +disabled, the client program has full and unfettered access to the part +of the address space used internally by \fIvalgrind\fP. This can cause +unexplained crashes and false error reports, so it is best left enabled. + .TP .B @@ -191,12 +349,14 @@ all process resources when a process exits anyway, so it would just slow things down. + .RS .PP The glibc authors realised that this behaviour causes leak checkers, -such as Valgrind, to falsely report leaks in glibc, when a leak check is -done at exit. In order to avoid this, they provided a routine called -__libc_freeres specifically to make glibc release all memory it has -allocated. The MemCheck and AddrCheck tools therefore try and run +such as \fIvalgrind\fP, to falsely report leaks in glibc, when a leak +check is done at exit. In order to avoid this, they provided a routine +called __libc_freeres specifically to make glibc release all memory it +has allocated. The MemCheck and AddrCheck tools therefore try and run __libc_freeres at exit. + .PP Unfortunately, in some versions of glibc, __libc_freeres is sufficiently @@ -207,12 +367,13 @@ although at the cost of possibly falsely reporting space leaks in libc.so. .RE + .TP .B ---sanity-level=<number> [default: 1] -Set the level of sanity checking to perform. -.TP -.B ---show-below-main -XXX +--show-below-main=<yes|no> [default: no] +When enabled, this option causes full stack backtraces to be emited, +including the part before \fImain\fP in your program (subject to the +\fI--num-callers\fP option.) When disabled, only the part of the stack +backtrace up to and including main is printed. + .TP .B @@ -220,95 +381,111 @@ When enabled, each x86 insn is translated separately into instrumented code. When disabled, translation is done on a per-basic-block basis, -giving much better translations. +giving much better translations. This is needed when running +\fIvalgrind\fP under \fIvalgrind\fP. + .TP .B ---sloppy-malloc -XXX +--sloppy-malloc=<yes|no> [default: no] +When enabled, \fIvalgrind\fP rounds all memory allocation request sizes +up to 4 bytes. + .TP .B ---suppressions=<filename> [default: $PREFIX/lib/\fIvalgrind\fP/default.supp] -Specifies an extra file from which to read descriptions of errors to -suppress. You may specify up to 10 additional suppression files. +--time-stamp=<yes|no> [default: no] +When enabled, a time-stamp is added to all log messages. + .TP .B ---time-stamp -XXX +--weird-hacks=hack1,hack2,\.\.\. +Pass miscellaneous hints to \fIvalgrind\fP which slightly modify the +simulated behaviour in nonstandard or dangerous ways, possibly to help +the simulation of strange features. By default no hacks are enabled. Use +with caution! Currently known hacks are: + +.RS .TP .B ---tool -XXX +- lax-ioctls +If \fIvalgrind\fP encounters an \fIioctl\fP that it doesn't understand, +it normally prints a warning message before continuing. Specifying the +lax-ioctls hack tells \fIvalgrind\fP to be very lax about ioctl handling +and assume that unknown ioctls just behave correctly. .TP .B ---trace-children=<yes|no> [default: no] -When enabled, Valgrind will trace into child processes. This is confusing -and usually not what you want, so is disabled by default. +- ioctl-mmap +Tell \fIvalgrind\fP to search for new memory mappings after an unknown +\fIioctl\fP call. +.RE + +.SH CORE DEBUGGING OPTIONS + .TP .B ---trace-codegen=<yes|no> [default: no] -XXX +--profile=<yes|no> [default: no] +When enabled, does crude internal profiling of \fIvalgrind\fP itself. This +is not for profiling your programs. Rather it is to allow the developers +to assess where \fIvalgrind\fP is spending its time. The tools must be +built for profiling for this to work. + .TP .B ---trace-malloc=<yes|no> [default: no] -Enable/disable tracing of malloc/free (et al) intercepts. +--sanity-level=<number> [default: 1] +Set the level of sanity checking to perform. This is used for debugging +\fIvalgrind\fP. Setting this to 2 or higher can cause more internal +sanity checks to be performed, but can slow your program down +appreciably. Setting this to 0 disables sanity checks. + .TP .B ---trace-redir=<yes|no> [default: no] -XXX +--trace-codegen=<bitmask> +Produce lots of output showing exactly how \fIvalgrind\fP is translating +each basic block. The argument to this option is a 5-bit wide bitmask. +Each bit refers to a specific feature to trace. If the bit is 1, the +feature is traced. If it is 0, the feature is not traced. + +.RS +The traced features are: .TP -.B ---trace-sched=<yes|no> [default: no] -Enable/disable tracing of thread scheduling events. +Bit 1: basic-block disassembly .TP -.B ---trace-signals=<yes|no> [default: no] -Enable/disable tracing of signal handling. +Bit 2: optimization phase .TP -.B ---trace-syscalls=<yes|no> [default: no] -Enable/disable tracing of system call intercepts. +Bit 3: tool instrumentation .TP -.B ---trace-symtab=<yes|no> [default: no] -Enable/disable tracing of symbol table reading. +Bit 4: register allocation +.TP +Bit 5: final code generation +.RE + .TP .B ---track-fds=<yes|no> [default: no] -XXX +--trace-malloc=<yes|no> [default: no] +Enable or disable tracing of malloc, free and other memory-manager calls. + .TP .B --v --verbose -Be more verbose. Gives extra information on various aspects of your -program, such as: the shared objects loaded, the suppressions used, -the progress of the instrumentation and execution engines, and warnings -about unusual behaviour. Repeating the flag increases the verbosity level. +--trace-redir=<yes|no> [default: no] +Enable or disable tracing of function redirection. + .TP .B ---version -Show the version number of the \fIvalgrind\fP core. Tools can have -their own version numbers. There is a scheme in place to ensure that -tools only execute when the core version is one they are known to work -with. This was done to minimise the chances of strange problems arising -from tool-vs-core version incompatibilities. +--trace-sched=<yes|no> [default: no] +Enable or disable tracing of thread scheduling events. + .TP .B ---weird-hacks=hack1,hack2,\.\.\. -Pass miscellaneous hints to Valgrind which slightly modify the simulated -behaviour in nonstandard or dangerous ways, possibly to help the -simulation of strange features. By default no hacks are enabled. Use -with caution! Currently known hacks are: -.RS +--trace-signals=<yes|no> [default: no] +Enable or disable tracing of signal handling. + .TP .B -- lax-ioctls -If \fIvalgrind\fP encounters an \fIioctl\fP that it doesn't understand, -it normally prints a warning message before continuing. Specifying the -lax-ioctls hack tells \fIvalgrind\fP to be very lax about ioctl handling -and assume that unknown ioctls just behave correctly. +--trace-syscalls=<yes|no> [default: no] +Enable or disable tracing of system call intercepts. + .TP .B -- ioctl-mmap -Tell \fIvalgrind\fP to search for new memory mappings after an unknown -\fIioctl\fP call. -.RE +--trace-symtab=<yes|no> [default: no] +Enable or disable tracing of symbol table reading. + .SH SEE ALSO /usr/share/doc/\fIvalgrind\fP/html/manual.html |