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
(13) |
2
(16) |
3
(10) |
4
(5) |
5
(1) |
6
|
|
7
(4) |
8
(3) |
9
(1) |
10
(1) |
11
(1) |
12
(3) |
13
(2) |
|
14
(8) |
15
(4) |
16
(17) |
17
(6) |
18
(20) |
19
(12) |
20
(1) |
|
21
(3) |
22
(17) |
23
(10) |
24
(9) |
25
|
26
|
27
(4) |
|
28
(4) |
29
(2) |
30
|
31
(5) |
|
|
|
|
From: Dirk M. <mu...@kd...> - 2003-12-02 20:32:11
|
CVS commit by mueller: customize page title M +1 -0 feedback.html 1.5 M +8 -3 header.inc 1.8 --- devel-home/valgrind/feedback.html #1.4:1.5 @@ -1,3 +1,4 @@ <?php + $page_title = "Sending Feedback"; include "header.inc" ?> --- devel-home/valgrind/header.inc #1.7:1.8 @@ -1,7 +1,12 @@ -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" -"http://www.w3.org/TR/html4/loose.dtd"> +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html> <head> -<title>Valgrind</title> +<?php + if (isset($page_title)) + $title = "Valgrind - $page_title"; + else + $title = "Valgrind"; +?> +<title><?php print $title; ?></title> <link rel="stylesheet" type="text/css" href="style.css"> </head> |
|
From: Nicholas N. <nj...@ca...> - 2003-12-02 18:53:07
|
CVS commit by nethercote: Update, for having added survey results. M +3 -8 feedback.html 1.4 --- devel-home/valgrind/feedback.html #1.3:1.4 @@ -14,16 +14,11 @@ <br>Jeremy Fitzhardinge (jeremy at goop dot org) <p> +If you want to give detailed, general feedback, please fill out our +<a href="survey2">survey</a>. +<p> <h3>Website</h3> Please send feedback about this website to Nick Nethercote (njn25 at cam dot ac dot uk). - -<h3>Survey</h3> -In November 2003 we ran a survey, and have some results. They will be put up -soon. -<p> -We're always interested to hear about what you think of Valgrind, and how you -are using it. We will soon have an updated survey for you to fill out. -Filling this out will help us to continually improve Valgrind. <p> |
|
From: Nicholas N. <nj...@ca...> - 2003-12-02 15:34:10
|
CVS commit by nethercote: Whoops... back out changes accidentally made to this file with the last, unrelated, commit. Sorry. M +59 -21 README 1.14 --- valgrind/README #1.13:1.14 @@ -2,15 +2,14 @@ Release notes for Valgrind, version 1.0.0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -> We're well past 1.0.0. I propose removing the version number here; -> it doesn't contribute anything, and just gets out-of-date. - KDE3 developers: please read also README_KDE3_FOLKS for guidance about how to debug KDE3 applications with Valgrind. -> I propose removing README_KDE3_FOLKS, and this reference to it; I -> think Valgrind has been around long enough that KDE developers don't -> need separate instructions. +If you are building a binary package of Valgrind for distribution, +please read README_PACKAGERS. It contains some important information. + +If you are developing Valgrind, please read README_DEVELOPERS. It contains +some useful information. -[snip] +For instructions on how to build/install, see the end of this file. Valgrind works best on systems with glibc-2.1.X or 2.2.X, and with gcc @@ -20,13 +19,28 @@ optimisation. Valgrind-1.0.X also can't handle glibc-2.3.X systems. -> Out of date: I think glibc-2.3.X is ok, right? Also gcc-3.1 is ok? Executive Summary ~~~~~~~~~~~~~~~~~ +Valgrind is a tool to help you find memory-management problems in your +programs. When a program is run under Valgrind's supervision, all +reads and writes of memory are checked, and calls to +malloc/new/free/delete are intercepted. As a result, Valgrind can +detect problems such as: + + Use of uninitialised memory + Reading/writing memory after it has been free'd + Reading/writing off the end of malloc'd blocks + Reading/writing inappropriate areas on the stack + Memory leaks -- where pointers to malloc'd blocks are lost forever + Passing of uninitialised and/or unaddressible memory to system calls + Mismatched use of malloc/new/new [] vs free/delete/delete [] + Some abuses of the POSIX pthread API + +Problems like these can be difficult to find by other means, often +lying undetected for long periods, then causing occasional, +difficult-to-diagnose crashes. -> This summary doesn't account for the core/tool split. Should be -> similar to the overview on the website. - -[snip] +When Valgrind detects such a problem, it can, if you like, attach GDB +to your program, so you can poke around and see what's going on. Valgrind is closely tied to details of the CPU, operating system and @@ -40,7 +54,4 @@ least. -> Out of date... could make more generic, eg. works on most/all common -> Linux distros - Valgrind is licensed under the GNU General Public License, version 2. Read the file COPYING in the source distribution for details. @@ -55,12 +66,39 @@ docs/techdocs.html. -> These paths are incorrect. -[snip] +Building and installing it +~~~~~~~~~~~~~~~~~~~~~~~~~~ +To install from CVS : -Julian Seward (js...@ac...) -1 July 2002 + 0. Check out the code from CVS, following the instructions at + http://developer.kde.org/source/anoncvs.html. The 'modulename' is + "valgrind". + + 1. cd into the source directory. + + 2. Run ./autogen.sh to setup the environment (you need the standard + autoconf tools to do so). -> out of date, I suggest removing the date, and saying "report bugs to -> valgrind.kde.org" or similar. +To install from a tar.gz archive: + 3. Run ./configure, with some options if you wish. The standard + options are documented in the INSTALL file. The only interesting + one is the usual --prefix=/where/you/want/it/installed. + + 4. Do "make". + + 5. Do "make install", possibly as root if the destination permissions + require that. + + 6. See if it works. Try "valgrind ls -l". Either this works, + or it bombs out complaining it can't find argc/argv/envp. + In that case, mail me a bug report. + +Important! Do not move the valgrind installation into a place +different from that specified by --prefix at build time. This will +cause things to break in subtle ways, mostly when Valgrind handles +fork/exec calls. + + +Julian Seward (js...@ac...) +1 July 2002 |
|
From: Nicholas N. <nj...@ca...> - 2003-12-02 15:27:30
|
CVS commit by nethercote: Patch from Tom Hughes: This patch extends the SFENCE support that is already present to include support for LFENCE and MFENCE as well. It also stops CLFLUSH being mistaken for SFENCE by checking the top two bits of the MODRM byte. M +21 -59 README 1.13 M +5 -3 coregrind/vg_to_ucode.c 1.114 --- valgrind/README #1.12:1.13 @@ -2,14 +2,15 @@ Release notes for Valgrind, version 1.0.0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +> We're well past 1.0.0. I propose removing the version number here; +> it doesn't contribute anything, and just gets out-of-date. + KDE3 developers: please read also README_KDE3_FOLKS for guidance about how to debug KDE3 applications with Valgrind. -If you are building a binary package of Valgrind for distribution, -please read README_PACKAGERS. It contains some important information. - -If you are developing Valgrind, please read README_DEVELOPERS. It contains -some useful information. +> I propose removing README_KDE3_FOLKS, and this reference to it; I +> think Valgrind has been around long enough that KDE developers don't +> need separate instructions. -For instructions on how to build/install, see the end of this file. +[snip] Valgrind works best on systems with glibc-2.1.X or 2.2.X, and with gcc @@ -19,28 +20,13 @@ optimisation. Valgrind-1.0.X also can't handle glibc-2.3.X systems. +> Out of date: I think glibc-2.3.X is ok, right? Also gcc-3.1 is ok? Executive Summary ~~~~~~~~~~~~~~~~~ -Valgrind is a tool to help you find memory-management problems in your -programs. When a program is run under Valgrind's supervision, all -reads and writes of memory are checked, and calls to -malloc/new/free/delete are intercepted. As a result, Valgrind can -detect problems such as: - - Use of uninitialised memory - Reading/writing memory after it has been free'd - Reading/writing off the end of malloc'd blocks - Reading/writing inappropriate areas on the stack - Memory leaks -- where pointers to malloc'd blocks are lost forever - Passing of uninitialised and/or unaddressible memory to system calls - Mismatched use of malloc/new/new [] vs free/delete/delete [] - Some abuses of the POSIX pthread API - -Problems like these can be difficult to find by other means, often -lying undetected for long periods, then causing occasional, -difficult-to-diagnose crashes. -When Valgrind detects such a problem, it can, if you like, attach GDB -to your program, so you can poke around and see what's going on. +> This summary doesn't account for the core/tool split. Should be +> similar to the overview on the website. + +[snip] Valgrind is closely tied to details of the CPU, operating system and @@ -54,4 +40,7 @@ least. +> Out of date... could make more generic, eg. works on most/all common +> Linux distros + Valgrind is licensed under the GNU General Public License, version 2. Read the file COPYING in the source distribution for details. @@ -66,39 +55,12 @@ docs/techdocs.html. +> These paths are incorrect. -Building and installing it -~~~~~~~~~~~~~~~~~~~~~~~~~~ -To install from CVS : - - 0. Check out the code from CVS, following the instructions at - http://developer.kde.org/source/anoncvs.html. The 'modulename' is - "valgrind". - - 1. cd into the source directory. - - 2. Run ./autogen.sh to setup the environment (you need the standard - autoconf tools to do so). - -To install from a tar.gz archive: - - 3. Run ./configure, with some options if you wish. The standard - options are documented in the INSTALL file. The only interesting - one is the usual --prefix=/where/you/want/it/installed. - - 4. Do "make". - - 5. Do "make install", possibly as root if the destination permissions - require that. - - 6. See if it works. Try "valgrind ls -l". Either this works, - or it bombs out complaining it can't find argc/argv/envp. - In that case, mail me a bug report. - -Important! Do not move the valgrind installation into a place -different from that specified by --prefix at build time. This will -cause things to break in subtle ways, mostly when Valgrind handles -fork/exec calls. - +[snip] Julian Seward (js...@ac...) 1 July 2002 + +> out of date, I suggest removing the date, and saying "report bugs to +> valgrind.kde.org" or similar. + --- valgrind/coregrind/vg_to_ucode.c #1.113:1.114 @@ -3495,7 +3495,9 @@ static Addr disInstr ( UCodeBlock* cb, A } - /* SFENCE -- flush all pending store operations to memory */ + /* LFENCE/MFENCE/SFENCE -- flush pending operations to memory */ if (insn[0] == 0x0F && insn[1] == 0xAE - && (gregOfRM(insn[2]) == 7)) { + && (epartIsReg(insn[2])) + && (gregOfRM(insn[2]) >= 5 && gregOfRM(insn[2]) <= 7)) + { vg_assert(sz == 4); eip += 3; |
|
From: Nicholas N. <nj...@ca...> - 2003-12-02 15:26:22
|
CVS commit by nethercote:
Patch from Tom Hughes:
This patch extends the SFENCE support that is already present to include
support for LFENCE and MFENCE as well. It also stops CLFLUSH being mistaken
for SFENCE by checking the top two bits of the MODRM byte.
MERGE TO HEAD
M +5 -3 vg_to_ucode.c 1.87.2.13
--- valgrind/coregrind/vg_to_ucode.c #1.87.2.12:1.87.2.13
@@ -3791,7 +3791,9 @@ static Addr disInstr ( UCodeBlock* cb, A
}
- /* SFENCE -- flush all pending store operations to memory */
+ /* LFENCE/MFENCE/SFENCE -- flush pending operations to memory */
if (insn[0] == 0x0F && insn[1] == 0xAE
- && (gregOfRM(insn[2]) == 7)) {
+ && (epartIsReg(insn[2]))
+ && (gregOfRM(insn[2]) >= 5 && gregOfRM(insn[2]) <= 7))
+ {
vg_assert(sz == 4);
eip += 3;
|
|
From: Nicholas N. <nj...@ca...> - 2003-12-02 15:15:36
|
Hi, Our README file sucks. This is bad, as it's going to be the first thing a lot of new Valgrind users read. It says things like: "Release notes for Valgrind 1.0.0", says Valgrind works on old distros like RH7.2, says it has problems with gcc 3.1 and glibc 2.3.X, and the description of Valgrind pre-dates the whole core/tool split. I think files like these are best written in a way that doesn't require updating, because files like these rarely get updated -- nobody bothers. So I include below the changes I think should be made; my comments are written on lines beginning with '>'. If no-one complains, I'll probably wade in and make the changes sometime soon. N Release notes for Valgrind, version 1.0.0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > We're well past 1.0.0. I suggest removing the version number here; > it doesn't contribute anything, and just gets out-of-date. KDE3 developers: please read also README_KDE3_FOLKS for guidance about how to debug KDE3 applications with Valgrind. > I suggest removing README_KDE3_FOLKS, and this reference to it; I think > Valgrind has been around long enough that KDE developers don't need > separate instructions (and it would be one less file to keep up-to-date). [snip] Valgrind works best on systems with glibc-2.1.X or 2.2.X, and with gcc versions prior to 3.1. gcc-3.1 works, but generates code which causes valgrind to report many false errors. For now, try to use a gcc prior to 3.1; if you can't, at least compile your application without optimisation. Valgrind-1.0.X also can't handle glibc-2.3.X systems. > Out of date: I think glibc-2.3.X is ok, right? Also gcc-3.1 is ok? > I suggest keeping this pretty generic, or removing it completely, perhaps replacing it with something like "works with most setups; see the FAQ if you have problems". Executive Summary ~~~~~~~~~~~~~~~~~ > This summary doesn't account for the core/tool split. Should be > similar to the overview on the website. [snip] Valgrind is closely tied to details of the CPU, operating system and to a less extent, compiler and basic C libraries. This makes it difficult to make it portable, so I have chosen at the outset to concentrate on what I believe to be a widely used platform: Red Hat Linux 7.2, on x86s. I believe that it will work without significant difficulty on other x86 GNU/Linux systems which use the 2.4 kernel and GNU libc 2.2.X, for example SuSE 7.1 and Mandrake 8.0. This version 1.0 release is known to work on Red Hats 6.2, 7.2 and 7.3, at the very least. > Out of date... could make more generic, eg. works on most/all common > Linux distros [snip] Documentation ~~~~~~~~~~~~~ A comprehensive user guide is supplied. Point your browser at docs/index.html. If your browser doesn't like frames, point it instead at docs/manual.html. There's also detailed, although somewhat out of date, documentation of how valgrind works, in docs/techdocs.html. > These paths are incorrect. [snip] Julian Seward (js...@ac...) 1 July 2002 > out of date, I suggest removing the date, and saying "report bugs to > valgrind.kde.org" or similar. |
|
From: Nicholas N. <nj...@ca...> - 2003-12-02 14:57:43
|
CVS commit by nethercote:
Tools using shadow memory can't handle the first 64KB being mapped, because
they rely on this area being unmapped for their quick sanity check. This
commit make Valgrind refuse to mmap() this area. Added a regtest for it.
A memcheck/tests/zeropage.c 1.1 [POSSIBLY UNSAFE: printf] [no copyright]
A memcheck/tests/zeropage.stderr.exp 1.1
A memcheck/tests/zeropage.vgtest 1.1
M +12 -0 coregrind/vg_syscalls.c 1.62
M +4 -2 memcheck/tests/Makefile.am 1.30
--- valgrind/coregrind/vg_syscalls.c #1.61:1.62
@@ -3205,4 +3205,12 @@ PRE(mkdir)
}
+void check_mmap_start(ThreadState* tst, Addr start, Int flags)
+{
+ /* Refuse to mmap the first 64KB of memory, so that the cheap sanity test
+ for tools using shadow memory works. */
+ if (start < 65536 && (flags & VKI_MAP_FIXED))
+ tst->m_eax = -VKI_EINVAL;
+}
+
PRE(mmap2)
{
@@ -3215,4 +3223,6 @@ PRE(mmap2)
MAYBE_PRINTF("mmap2 ( %p, %d, %d, %d, %d, %d )\n",
arg1, arg2, arg3, arg4, arg5, arg6 );
+
+ check_mmap_start(tst, arg1, arg4);
}
@@ -3241,4 +3251,6 @@ PRE(mmap)
MAYBE_PRINTF("mmap ( %p, %d, %d, %d, %d, %d )\n",
a1, a2, a3, a4, a5, a6 );
+
+ check_mmap_start(tst, a1, a4);
}
--- valgrind/memcheck/tests/Makefile.am #1.29:1.30
@@ -63,5 +63,6 @@
threadederrno.stderr.exp threadederrno.stdout.exp \
threadederrno.vgtest \
- writev.stderr.exp writev.vgtest
+ writev.stderr.exp writev.vgtest \
+ zeropage.stderr.exp zeropage.vgtest
check_PROGRAMS = \
@@ -74,5 +75,5 @@
realloc1 realloc2 realloc3 sigaltstack signal2 supp1 supp2 suppfree \
trivialleak tronical weirdioctl \
- mismatches new_override metadata threadederrno writev
+ mismatches new_override metadata threadederrno writev zeropage
AM_CPPFLAGS = -I$(top_srcdir)/include
@@ -126,4 +127,5 @@
threadederrno_LDADD = -lpthread
writev_SOURCES = writev.c
+zeropage_SOURCES = zeropage.c
# C++ ones
|
|
From: Nicholas N. <nj...@ca...> - 2003-12-02 10:41:47
|
CVS commit by nethercote:
Grouped options in the usage message so they're a bit easier to understand.
M +23 -26 vg_main.c 1.127
--- valgrind/coregrind/vg_main.c #1.126:1.127
@@ -637,7 +637,6 @@ static void usage ( void )
"usage: valgrind [options] prog-and-args\n"
"\n"
-" core user options, with defaults in [ ], are:\n"
+" common user options for all Valgrind tools, with defaults in [ ]:\n"
" --tool=<name> Use the Valgrind tool named <name> [memcheck]\n"
-
" --help show this message\n"
" --version show version\n"
@@ -645,7 +643,20 @@ static void usage ( void )
" -q --quiet run silently; only print error msgs\n"
" -v --verbose be more verbose, incl counts of errors\n"
-
" --trace-children=no|yes Valgrind-ise child processes? [no]\n"
-
+" --track-fds=no|yes Track open file descriptors? [no]\n"
+"\n"
+" uncommon user options for all Valgrind tools:\n"
+" --run-libc-freeres=no|yes Free up glibc memory at exit? [yes]\n"
+" --weird-hacks=hack1,hack2,... [none]\n"
+" recognised hacks are: ioctl-VTIME truncate-writes lax-ioctls\n"
+" --signal-polltime=<time> time, in mS, we should poll for signals.\n"
+" Only applies for older kernels which need\n"
+" signal routing [50]\n"
+" --lowlat-signals=no|yes improve wake-up latency when a thread receives\n"
+" a signal [no]\n"
+" --lowlat-syscalls=no|yes improve wake-up latency when a thread's\n"
+" syscall completes [no]\n"
+"\n"
+" user options for Valgrind tools that report errors:\n"
" --logfile-fd=<number> file descriptor for messages [2=stderr]\n"
" --logfile=<file> log messages to <file>.pid<pid>\n"
@@ -659,27 +669,13 @@ static void usage ( void )
" --gen-suppressions=no|yes print suppressions for errors detected [no]\n"
-" --track-fds=no|yes Track open file descriptors? [no]\n"
-
" --gdb-attach=no|yes start GDB when errors detected? [no]\n"
" --gdb-path=/path/to/gdb path to the GDB to use [/usr/bin/gdb]\n"
" --input-fd=<number> file descriptor for (gdb) input [0=stdin]\n"
-
-" --run-libc-freeres=no|yes Free up glibc memory at exit? [yes]\n"
-" --weird-hacks=hack1,hack2,... [none]\n"
-" recognised hacks are: ioctl-VTIME truncate-writes lax-ioctls\n"
-" --signal-polltime=<time> time, in mS, we should poll for signals.\n"
-" Only applies for older kernels which need\n"
-" signal routing [50]\n"
-" --lowlat-signals=no|yes improve wake-up latency when a thread receives\n"
-" a signal [no]\n"
-" --lowlat-syscalls=no|yes improve wake-up latency when a thread's\n"
-" syscall completes [no]\n"
"\n"
-" %s tool user options:\n";
-
+" user options for %s:\n";
Char* usage2 =
"\n"
-" core options for debugging Valgrind itself are:\n"
+" debugging options for all Valgrind tools:\n"
" --sanity-level=<number> level of sanity checking to do [1]\n"
" --single-step=no|yes translate each instr separately? [no]\n"
@@ -695,10 +691,11 @@ static void usage ( void )
" --stop-after=<number> switch to real CPU after executing\n"
" <number> basic blocks [infinity]\n"
-" --dump-error=<number> show translation for basic block\n"
-" associated with <number>'th\n"
-" error context [0=don't show any]\n"
" --wait-for-gdb=yes|no pause on startup to wait for gdb attach\n"
"\n"
-" %s tool debugging options:\n";
+" debugging options for Valgrind tools that report errors\n"
+" --dump-error=<number> show translation for basic block associated\n"
+" with <number>'th error context [0=show none]\n"
+"\n"
+" debugging options for %s:\n";
Char* usage3 =
|
|
From: Jeremy F. <je...@go...> - 2003-12-02 10:36:01
|
On Mon, 2003-12-01 at 06:23, Nicholas Nethercote wrote: > Ah. Should I back out the changes? In HEAD and stable branch? Yeah, I think so. Without knowing the details of why this came up, the missing gettid is probably a symptom of some other problem. As Tom said, just calling gettid probably isn't producing any useful results, and there's no sensible way you can use the tid anyway. J |
|
From: Nicholas N. <nj...@ca...> - 2003-12-02 10:22:31
|
CVS commit by nethercote:
Make --leak-check observe -q properly -- only prints out errors, not general
info and summaries.
M +23 -19 mac_leakcheck.c 1.7.2.2
M +0 -11 tests/nanoleak.stderr.exp 1.7.2.1
M +0 -11 tests/nanoleak_supp.stderr.exp 1.2.2.1
M +0 -11 tests/trivialleak.stderr.exp 1.6.2.1
--- valgrind/memcheck/mac_leakcheck.c #1.7.2.1:1.7.2.2
@@ -407,5 +407,7 @@ void MAC_(do_detect_memory_leaks) (
}
- VG_(message)(Vg_UserMsg, "searching for pointers to %d not-freed blocks.",
+ if (VG_(clo_verbosity) > 0)
+ VG_(message)(Vg_UserMsg,
+ "searching for pointers to %d not-freed blocks.",
lc_n_shadows );
@@ -427,4 +429,5 @@ void MAC_(do_detect_memory_leaks) (
);
+ if (VG_(clo_verbosity) > 0)
VG_(message)(Vg_UserMsg, "checked %d bytes.", bytes_notified);
@@ -512,4 +515,5 @@ void MAC_(do_detect_memory_leaks) (
}
+ if (VG_(clo_verbosity) > 0) {
VG_(message)(Vg_UserMsg, "");
VG_(message)(Vg_UserMsg, "LEAK SUMMARY:");
@@ -528,5 +532,5 @@ void MAC_(do_detect_memory_leaks) (
"To see them, rerun with: --show-reachable=yes");
}
- VG_(message)(Vg_UserMsg, "");
+ }
VG_(free) ( lc_shadows );
--- valgrind/memcheck/tests/nanoleak.stderr.exp #1.7:1.7.2.1
@@ -1,4 +1,2 @@
-searching for pointers to 1 not-freed blocks.
-checked ... bytes.
1000 bytes in 1 blocks are definitely lost in loss record 1 of 1
@@ -7,11 +5,2 @@
by 0x........: __libc_start_main (...libc...)
by 0x........: ...
-
-LEAK SUMMARY:
- definitely lost: 1000 bytes in 1 blocks.
- possibly lost: 0 bytes in 0 blocks.
- still reachable: 0 bytes in 0 blocks.
- suppressed: 0 bytes in 0 blocks.
-Reachable blocks (those to which a pointer was found) are not shown.
-To see them, rerun with: --show-reachable=yes
-
--- valgrind/memcheck/tests/nanoleak_supp.stderr.exp #1.2:1.2.2.1
@@ -1,11 +0,0 @@
-searching for pointers to 1 not-freed blocks.
-checked ... bytes.
-
-LEAK SUMMARY:
- definitely lost: 0 bytes in 0 blocks.
- possibly lost: 0 bytes in 0 blocks.
- still reachable: 0 bytes in 0 blocks.
- suppressed: 1000 bytes in 1 blocks.
-Reachable blocks (those to which a pointer was found) are not shown.
-To see them, rerun with: --show-reachable=yes
-
--- valgrind/memcheck/tests/trivialleak.stderr.exp #1.6:1.6.2.1
@@ -1,4 +1,2 @@
-searching for pointers to 1000 not-freed blocks.
-checked ... bytes.
1000 bytes in 1000 blocks are definitely lost in loss record 1 of 1
@@ -7,11 +5,2 @@
by 0x........: main (trivialleak.c:12)
by 0x........: __libc_start_main (...libc...)
-
-LEAK SUMMARY:
- definitely lost: 1000 bytes in 1000 blocks.
- possibly lost: 0 bytes in 0 blocks.
- still reachable: 0 bytes in 0 blocks.
- suppressed: 0 bytes in 0 blocks.
-Reachable blocks (those to which a pointer was found) are not shown.
-To see them, rerun with: --show-reachable=yes
-
|
|
From: Nicholas N. <nj...@ca...> - 2003-12-02 10:18:15
|
CVS commit by nethercote:
Make --leak-check observe -q properly -- only prints out errors, not general
info and summaries.
MERGE TO STABLE
M +23 -19 mac_leakcheck.c 1.11
M +0 -11 tests/nanoleak.stderr.exp 1.9
M +0 -11 tests/nanoleak_supp.stderr.exp 1.3
M +0 -11 tests/trivialleak.stderr.exp 1.8
--- valgrind/memcheck/mac_leakcheck.c #1.10:1.11
@@ -422,5 +422,7 @@ void MAC_(do_detect_memory_leaks) (
}
- VG_(message)(Vg_UserMsg, "searching for pointers to %d not-freed blocks.",
+ if (VG_(clo_verbosity) > 0)
+ VG_(message)(Vg_UserMsg,
+ "searching for pointers to %d not-freed blocks.",
lc_n_shadows );
@@ -442,4 +444,5 @@ void MAC_(do_detect_memory_leaks) (
);
+ if (VG_(clo_verbosity) > 0)
VG_(message)(Vg_UserMsg, "checked %d bytes.", bytes_notified);
@@ -527,4 +530,5 @@ void MAC_(do_detect_memory_leaks) (
}
+ if (VG_(clo_verbosity) > 0) {
VG_(message)(Vg_UserMsg, "");
VG_(message)(Vg_UserMsg, "LEAK SUMMARY:");
@@ -543,5 +547,5 @@ void MAC_(do_detect_memory_leaks) (
"To see them, rerun with: --show-reachable=yes");
}
- VG_(message)(Vg_UserMsg, "");
+ }
VG_(free) ( lc_shadows );
--- valgrind/memcheck/tests/nanoleak.stderr.exp #1.8:1.9
@@ -1,15 +1,4 @@
-searching for pointers to 1 not-freed blocks.
-checked ... bytes.
1000 bytes in 1 blocks are definitely lost in loss record 1 of 1
at 0x........: malloc (vg_replace_malloc.c:...)
by 0x........: main (nanoleak.c:6)
-
-LEAK SUMMARY:
- definitely lost: 1000 bytes in 1 blocks.
- possibly lost: 0 bytes in 0 blocks.
- still reachable: 0 bytes in 0 blocks.
- suppressed: 0 bytes in 0 blocks.
-Reachable blocks (those to which a pointer was found) are not shown.
-To see them, rerun with: --show-reachable=yes
-
--- valgrind/memcheck/tests/nanoleak_supp.stderr.exp #1.2:1.3
@@ -1,11 +0,0 @@
-searching for pointers to 1 not-freed blocks.
-checked ... bytes.
-
-LEAK SUMMARY:
- definitely lost: 0 bytes in 0 blocks.
- possibly lost: 0 bytes in 0 blocks.
- still reachable: 0 bytes in 0 blocks.
- suppressed: 1000 bytes in 1 blocks.
-Reachable blocks (those to which a pointer was found) are not shown.
-To see them, rerun with: --show-reachable=yes
-
--- valgrind/memcheck/tests/trivialleak.stderr.exp #1.7:1.8
@@ -1,4 +1,2 @@
-searching for pointers to 1000 not-freed blocks.
-checked ... bytes.
1000 bytes in 1000 blocks are definitely lost in loss record 1 of 1
@@ -6,11 +4,2 @@
by 0x........: test (trivialleak.c:8)
by 0x........: main (trivialleak.c:12)
-
-LEAK SUMMARY:
- definitely lost: 1000 bytes in 1000 blocks.
- possibly lost: 0 bytes in 0 blocks.
- still reachable: 0 bytes in 0 blocks.
- suppressed: 0 bytes in 0 blocks.
-Reachable blocks (those to which a pointer was found) are not shown.
-To see them, rerun with: --show-reachable=yes
-
|
|
From: Nicholas N. <nj...@ca...> - 2003-12-02 10:06:15
|
CVS commit by nethercote: Added surveys page, linking to the results from the first one, and including an improved second version. A survey2 1.1 A surveys.html 1.1 M +1 -0 menu.inc 1.7 --- devel-home/valgrind/menu.inc #1.6:1.7 @@ -13,4 +13,5 @@ <dt><a href="cvs.html"> CVS Repository</a> <dt><a href="related.html"> Related Tools</a> +<dt><a href="surveys.html"> Surveys</a> <dt><a href="feedback.html"> Feedback</a> </dl> |
|
From: Nicholas N. <nj...@ca...> - 2003-12-02 09:36:03
|
CVS commit by nethercote:
Backing out bogus support for gettid() I added yesterday.
M +0 -7 vg_syscalls.c 1.61
--- valgrind/coregrind/vg_syscalls.c #1.60:1.61
@@ -1937,10 +1937,4 @@ PRE(getpid)
}
-PRE(gettid)
-{
- /* pid_t gettid(void); */
- MAYBE_PRINTF("gettid ()\n");
-}
-
PRE(getpgid)
{
@@ -4642,5 +4636,4 @@ static const struct sys_info sys_info[]
SYSB_(getgid32, False),
SYSB_(getpid, False),
- SYSB_(gettid, False),
SYSB_(getpgid, False),
SYSB_(getpgrp, False),
|
|
From: Nicholas N. <nj...@ca...> - 2003-12-02 09:35:06
|
CVS commit by nethercote:
Backing out bogus support for gettid() I added yesterday.
M +0 -8 vg_syscalls.c 1.40.2.11
--- valgrind/coregrind/vg_syscalls.c #1.40.2.10:1.40.2.11
@@ -1646,12 +1646,4 @@ void VG_(perform_assumed_nonblocking_sys
break;
-#if defined(__NR_gettid)
- case __NR_gettid: /* syscall 224 */
- /* pid_t gettid(void); */
- MAYBE_PRINTF("gettid ()\n");
- KERNEL_DO_SYSCALL(tid, res);
- break;
-#endif
-
case __NR_getpgid: /* syscall 132 */
/* pid_t getpgid(pid_t pid); */
|
|
From: Jeremy F. <je...@go...> - 2003-12-02 03:24:55
|
On Mon, 2003-12-01 at 06:37, Nicholas Nethercote wrote: > The C standard, section 7.20.3 (from > wwwold.dkuug.dk/jtc1/sc22/open/n2794/n2794.txt) says: > > The pointer returned if the allocation succeeds is suitably aligned so > that it may be assigned to a pointer to any type of object and then > used to access such an object or an array of such objects in the > space allocated (until the space is explicitly freed or > reallocated). > > I'm not sure what this actually means. For x86, does "suitably aligned" > have any meaning at all, since unaligned accesses are ok? Well, unaligned accesses are only OK by default. You can turn on alignment checking, and get faults on unaligned accesses. Also, SSE instructions have a 16-byte alignment requirement. I would say that we have to return malloc blocks at least 8-byte aligned (for doubles), and perhaps 16-byte aligned (for SSE). Returning 4-byte aligned blocks doesn't really help anyone, and breaks a lot of stuff. If someone really wants 4 byte alignment, they can always ask for it: --alignment=4. J |
|
From: Nicholas N. <nj...@ca...> - 2003-12-02 03:24:27
|
Hi, We've had a few problems with valgrind -q printing out more things than it should. Basically because it's easy to forget to wrap calls to VG_(message)() inside an "if (VG_(clo_verbosity)...)" condition. I think the way to fix this would be to augment VG_(message)() to take an additional integer parameter, that shows how important the message is. Ie. '0' would be shown even with -q, '1' would be shown normally, '2' with -v, '3' with -v -v. That way you couldn't add a VG_(message)() call without thinking about when it should be shown. Only problem is that the change would be moderately pervasive (I see 379 calls to VG_(message)() -- many of which occur together -- and 58 mentions of VG_(clo_verbosity)), and I don't want to cause merging hassles in people's (esp. Jeremy's) workspaces. Thoughts? N |