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
(3) |
|
2
(8) |
3
(19) |
4
(24) |
5
(23) |
6
(16) |
7
(33) |
8
(5) |
|
9
(4) |
10
(23) |
11
(22) |
12
(40) |
13
(30) |
14
(31) |
15
(17) |
|
16
(18) |
17
(20) |
18
(41) |
19
(36) |
20
(25) |
21
(8) |
22
(9) |
|
23
(17) |
24
(12) |
25
(15) |
26
(15) |
27
(16) |
28
(22) |
29
(6) |
|
30
(7) |
31
(10) |
|
|
|
|
|
|
From: <sv...@va...> - 2009-08-05 23:59:20
|
Author: njn
Date: 2009-08-06 00:59:05 +0100 (Thu, 06 Aug 2009)
New Revision: 10724
Log:
Overhaul the BBV manual chapter, mostly. Also tweak BBV's usage message to
match the docs better.
Modified:
trunk/docs/xml/quick-start-guide.xml
trunk/exp-bbv/bbv_main.c
trunk/exp-bbv/docs/bbv-manual.xml
Modified: trunk/docs/xml/quick-start-guide.xml
===================================================================
--- trunk/docs/xml/quick-start-guide.xml 2009-08-05 22:51:17 UTC (rev 10723)
+++ trunk/docs/xml/quick-start-guide.xml 2009-08-05 23:59:05 UTC (rev 10724)
@@ -61,11 +61,11 @@
<title>Running your program under Memcheck</title>
<para>If you normally run your program like this:</para>
-<programlisting> myprog arg1 arg2
+<programlisting> myprog arg1 arg2
</programlisting>
<para>Use this command line:</para>
-<programlisting> valgrind --leak-check=yes myprog arg1 arg2
+<programlisting> valgrind --leak-check=yes myprog arg1 arg2
</programlisting>
<para>Memcheck is the default tool. The <option>--leak-check</option>
Modified: trunk/exp-bbv/bbv_main.c
===================================================================
--- trunk/exp-bbv/bbv_main.c 2009-08-05 22:51:17 UTC (rev 10723)
+++ trunk/exp-bbv/bbv_main.c 2009-08-05 23:59:05 UTC (rev 10724)
@@ -537,7 +537,7 @@
else if VG_STR_CLO (arg, "--pc-out-file", clo_pc_out_file) {
generate_pc_file = True;
}
- else if VG_XACT_CLO (arg, "--instr-count-only", instr_count_only, True) {}
+ else if VG_BOOL_CLO (arg, "--instr-count-only", instr_count_only) {}
else {
return False;
}
@@ -547,10 +547,12 @@
static void bbv_print_usage(void)
{
- VG_(printf) (" --bb-out-file=<file> filename for basic block vector info\n");
- VG_(printf) (" --pc-out-file=<file> filename for basic block addresses and function names\n");
- VG_(printf) (" --interval-size=<num> interval size\n");
- VG_(printf) (" --instr-count-only only print total instruction count\n");
+ VG_(printf)(
+" --bb-out-file=<file> filename for BBV info\n"
+" --pc-out-file=<file> filename for BB addresses and function names\n"
+" --interval-size=<num> interval size\n"
+" --instr-count-only=yes|no only print total instruction count\n"
+ );
}
static void bbv_print_debug_usage(void)
Modified: trunk/exp-bbv/docs/bbv-manual.xml
===================================================================
--- trunk/exp-bbv/docs/bbv-manual.xml 2009-08-05 22:51:17 UTC (rev 10723)
+++ trunk/exp-bbv/docs/bbv-manual.xml 2009-08-05 23:59:05 UTC (rev 10724)
@@ -13,10 +13,10 @@
<title>Overview</title>
<para>
- A Basic Blocks Vector (BBV) is a list of all basic blocks entered
- during program execution, and a count of how many times each
- block was run (a basic block is a section of code
- with only one entry point and one exit point).
+ A basic block is a linear section of code with one entry point and one exit
+ point. A <emphasis>basic blocks vector</emphasis> (BBV) is a list of all
+ basic blocks entered during program execution, and a count of how many
+ times each basic block was run.
</para>
<para>
@@ -58,12 +58,14 @@
<para>
To quickly create a basic block vector file, you will call Valgrind
like this:
- <computeroutput>valgrind --tool=exp-bbv /bin/ls</computeroutput>
- In this case we are running on the "ls" program, but this
- can be any executable. By default a file called
+
+ <programlisting>valgrind --tool=exp-bbv /bin/ls</programlisting>
+
+ In this case we are running on <filename>/bin/ls</filename>,
+ but this can be any program. By default a file called
<computeroutput>bb.out.PID</computeroutput> will be created,
where PID is replaced by the process ID of the running process.
- This file is the basic block vector. For long-running programs
+ This file contains the basic block vector. For long-running programs
this file can be quite large, so it might be wise to compress
it with gzip or some other compression program.
</para>
@@ -82,7 +84,7 @@
-saveSimpointWeights results.weights]]></programlisting>
where bb.out.1234.gz is your compressed basic block vector file
- generated by Valgrind exp-bbv.
+ generated by BBV.
</para>
<para>
@@ -111,12 +113,47 @@
<sect1 id="bbv-manual.usage" xreflabel="BBV Usage">
<title>BBV Command Line Options</title>
-<para>
- BBV has various options that control the behavior of the plugin:
+<para> BBV-specific options are:</para>
+
<!-- start of xi:include in the manpage -->
<variablelist id="bbv.opts.list">
- <varlistentry id="opt.interval-size" xreflabel="--interval-size">
+ <varlistentry id="opt.bb-out-file" xreflabel="--bb-out-file">
+ <term>
+ <option><![CDATA[--bb-out-file=<name> [default: bb.out.%p] ]]></option>
+ </term>
+ <listitem>
+ <para>
+ This option selects the name of the basic block vector file. The
+ <option>%p</option> and <option>%q</option> format specifiers can be
+ used to embed the process ID and/or the contents of an environment
+ variable in the name, as is the case for the core option
+ <option><xref linkend="opt.log-file"/></option>.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="opt.pc-out-file" xreflabel="--pc-out-file">
+ <term>
+ <option><![CDATA[--pc-out-file=<name> [default: pc.out.%p] ]]></option>
+ </term>
+ <listitem>
+ <para>
+ This option selects the name of the PC file.
+ This file holds program counter addresses
+ and function name info for the various basic blocks.
+ This can be used in conjunction
+ with the basic block vector file to fast-forward via function names
+ instead of just instruction counts. The
+ <option>%p</option> and <option>%q</option> format specifiers can be
+ used to embed the process ID and/or the contents of an environment
+ variable in the name, as is the case for the core option
+ <option><xref linkend="opt.log-file"/></option>.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="opt.interval-size" xreflabel="--interval-size">
<term>
<option><![CDATA[--interval-size=<number> [default: 100000000] ]]></option>
</term>
@@ -143,57 +180,18 @@
</term>
<listitem>
<para>
- This option tells the tool to only display instruction
- count totals, and to not generate the
- actual BBV file. This is useful for debugging, and for
- gathering instruction count info without generating
- the large BBV files.
+ This option tells the tool to only display instruction count
+ totals, and to not generate the actual basic block vector file.
+ This is useful for debugging, and for gathering instruction count
+ info without generating the large basic block vector files.
</para>
</listitem>
</varlistentry>
- <varlistentry id="opt.bb-out-file" xreflabel="--bb-out-file">
- <term>
- <option><![CDATA[--bb-out-file=<name> [default: bb.out.%p] ]]></option>
- </term>
- <listitem>
- <para>
- This option selects the name of the basic block file. Default is
- bb.out.%p. The
- <option>%p</option> and <option>%q</option> format specifiers can be
- used to embed the process ID and/or the contents of an environment
- variable in the name, as is the case for the core option
- <option>--log-file</option>.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry id="opt.pc-out-file" xreflabel="--pc-out-file">
- <term>
- <option><![CDATA[--pc-out-file=<name> [default: pc.out.%p] ]]></option>
- </term>
- <listitem>
- <para>
- This option selects the name of the PC file.
- This file holds program counter addresses
- and function name info for the various basic blocks.
- This can be used in conjunction
- with the bbv file to fast-forward via function names
- instead of just instruction counts.
- The default filename is pc.out.%p.
- <option>%p</option> and <option>%q</option> format specifiers can be
- used to embed the process ID and/or the contents of an environment
- variable in the name, as is the case for the core option
- <option>--log-file</option>.
-
- </para>
- </listitem>
- </varlistentry>
</variablelist>
<!-- end of xi:include in the manpage -->
-</para>
-
</sect1>
<sect1 id="bbv-manual.fileformat" xreflabel="BBV File Format">
@@ -225,8 +223,8 @@
<para>
The entry count is multiplied by the number of instructions that are
in the basic block, in order to weigh the count so that instructions in
- small Basic Blocks aren't counted as more important than instructions
- in large Basic Blocks.
+ small basic blocks aren't counted as more important than instructions
+ in large basic blocks.
</para>
</sect1>
@@ -238,32 +236,32 @@
Valgrind provides all of the information necessary to create
BBV files. In the current implementation, all instructions
are instrumented. This is slower (by approximately a factor
- of two) than a method that instruments at the basic-block level,
+ of two) than a method that instruments at the basic block level,
but there are some complications (especially with rep prefix
detection) that make that method more difficult.
</para>
<para>
- Valgrind actually provides instrumentation at a super-block level.
- A super-block has one entry point but unlike basic-blocks can
+ Valgrind actually provides instrumentation at a superblock level.
+ A superblock has one entry point but unlike basic blocks can
have multiple exit points. Once a branch occurs into the middle
- of a block, it is split into a new basic-block. Because
+ of a block, it is split into a new basic block. Because
Valgrind cannot produce "true" basic blocks, the generated
BBV vectors will be different than those generated by other tools.
In practice this does not seem to affect the accuracy of the
SimPoint results. We do internally force the
<option>--vex-guest-chase-thresh=0</option>
- option to Valgrind which forces a more basic-block like
+ option to Valgrind which forces a more basic-block-like
behavior.
</para>
<para>
- When a super block is run for the first time, it is instrumented
+ When a superblock is run for the first time, it is instrumented
with our BBV routine. This adds a call to our instruction
counting function for each original instruction.
- The current superblock is looked up in an Ordered Set to find
+ The current superblock is looked up in an ordered set to find
a structure that holds block-specific statistics (the entry point
- address is the index into the hash table). We increment the
+ address is the index into the ordered set). We increment the
instruction count for this superblock and
also update the master instruction count.
If the master count overflows the interval size
@@ -283,7 +281,7 @@
</para>
<para>
- The exp-bbv tool also counts the fldcw instruction. This
+ BBV also counts the fldcw instruction. This
instruction is used on x86 machines when converting numbers
from floating point to integer (among other uses).
On Pentium 4 systems the retired instruction performance
@@ -300,8 +298,8 @@
<para>
BBV supports threaded programs. When a program has multiple threads,
- an additional BBV file is created for each thread (each additional
- file is the specified filename with the thread number
+ an additional basic block vector file is created for each thread (each
+ additional file is the specified filename with the thread number
appended at the end).
</para>
@@ -310,8 +308,8 @@
threaded workloads. The most common method is to run
SimPoint on each thread's results independently, and use
some method of deterministic execution to try to match the
- original workload. This should be possible with current
- exp-bbv.
+ original workload. This should be possible with the current
+ BBV.
</para>
</sect1>
@@ -320,8 +318,8 @@
<title>Validation</title>
<para>
- This plugin has been tested on x86, amd64, and ppc32 platforms.
- An earlier version of the plugin was tested in detail using
+ BBV has been tested on x86, amd64, and ppc32 platforms.
+ An earlier version of BBV was tested in detail using
hardware performance counters, this work is described in a paper
from the HiPEAC'08 conference, "Using Dynamic Binary Instrumentation
to Generate Multi-Platform SimPoints: Methodology and Accuracy" by
|
|
From: <sv...@va...> - 2009-08-05 22:51:34
|
Author: njn Date: 2009-08-05 23:51:17 +0100 (Wed, 05 Aug 2009) New Revision: 10723 Log: Document the 'cc' param of VG_(malloc) et al. Modified: trunk/include/pub_tool_mallocfree.h Modified: trunk/include/pub_tool_mallocfree.h =================================================================== --- trunk/include/pub_tool_mallocfree.h 2009-08-05 22:13:23 UTC (rev 10722) +++ trunk/include/pub_tool_mallocfree.h 2009-08-05 22:51:17 UTC (rev 10723) @@ -35,6 +35,8 @@ // These can be for allocating memory used by tools. // Nb: the allocators *always succeed* -- they never return NULL (Valgrind // will abort if they can't allocate the memory). +// The 'cc' is a string that identifies the allocation point. It's used when +// --profile-heap=yes is specified. extern void* VG_(malloc) ( HChar* cc, SizeT nbytes ); extern void VG_(free) ( void* p ); extern void* VG_(calloc) ( HChar* cc, SizeT n, SizeT bytes_per_elem ); |
|
From: Nicholas N. <n.n...@gm...> - 2009-08-05 22:50:11
|
On Thu, Aug 6, 2009 at 2:37 AM, xiaoming gu<xia...@gm...> wrote: > Hi, all. Does anyone know the purpose of the first argument for VG_(malloc)? > The function is with the prototype "extern void* VG_(malloc)(HChar* cc, > SizeT nbytes);". I checked the available tools and only found some magic > strings such as "mc.acb.1". Thanks. It's an identifier used by Valgrind's internal heap profiler, turned on with --profile-heap=yes. It just needs to be a unique string, the exact form doesn't really matter but it would make sense to follow the general pattern of the others. Nick |
|
From: <sv...@va...> - 2009-08-05 22:13:34
|
Author: njn Date: 2009-08-05 23:13:23 +0100 (Wed, 05 Aug 2009) New Revision: 10722 Log: Fix Lackey test breakage. Modified: trunk/lackey/tests/filter_stderr trunk/lackey/tests/true.stderr.exp Modified: trunk/lackey/tests/filter_stderr =================================================================== --- trunk/lackey/tests/filter_stderr 2009-08-05 08:08:18 UTC (rev 10721) +++ trunk/lackey/tests/filter_stderr 2009-08-05 22:13:23 UTC (rev 10722) @@ -8,4 +8,7 @@ sed "/^Lackey, an example Valgrind tool./ , /./ d" | # Filter all the numbers. -../../tests/filter_numbers +../../tests/filter_numbers | + +# Replace "call" with "calls" +sed "s/ call / calls /" Modified: trunk/lackey/tests/true.stderr.exp =================================================================== --- trunk/lackey/tests/true.stderr.exp 2009-08-05 08:08:18 UTC (rev 10721) +++ trunk/lackey/tests/true.stderr.exp 2009-08-05 22:13:23 UTC (rev 10722) @@ -1,6 +1,6 @@ -Counted ... calls to _dl_runtime_resolve() +Counted ... calls to main() Jccs: total: ... |
|
From: Nicholas N. <n.n...@gm...> - 2009-08-05 17:21:13
|
Nightly build on ocean32 ( Ubuntu 9.04, x86_64 (32-bit only) )
Started at 2009-08-06 03:00:01 EST
Ended at 2009-08-06 03:20:55 EST
Results differ from 24 hours ago
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... done
Running regression tests ... failed
Regression test results follow
== 482 tests, 11 stderr failures, 1 stdout failure, 0 post failures ==
memcheck/tests/origin5-bz2 (stderr)
lackey/tests/true (stderr)
none/tests/empty-exe (stderr)
none/tests/shell (stdout)
none/tests/shell (stderr)
none/tests/shell_valid1 (stderr)
none/tests/shell_valid2 (stderr)
none/tests/shell_valid3 (stderr)
none/tests/shell_zerolength (stderr)
helgrind/tests/pth_barrier3 (stderr)
helgrind/tests/tc06_two_races_xml (stderr)
exp-ptrcheck/tests/supp (stderr)
=================================================
== Results from 24 hours ago ==
=================================================
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... done
Running regression tests ... failed
Regression test results follow
== 482 tests, 9 stderr failures, 1 stdout failure, 0 post failures ==
memcheck/tests/origin5-bz2 (stderr)
none/tests/empty-exe (stderr)
none/tests/shell (stdout)
none/tests/shell (stderr)
none/tests/shell_valid1 (stderr)
none/tests/shell_valid2 (stderr)
none/tests/shell_valid3 (stderr)
none/tests/shell_zerolength (stderr)
helgrind/tests/tc06_two_races_xml (stderr)
exp-ptrcheck/tests/supp (stderr)
=================================================
== Difference between 24 hours ago and now ==
=================================================
*** old.short Thu Aug 6 03:10:32 2009
--- new.short Thu Aug 6 03:20:55 2009
***************
*** 8,11 ****
! == 482 tests, 9 stderr failures, 1 stdout failure, 0 post failures ==
memcheck/tests/origin5-bz2 (stderr)
none/tests/empty-exe (stderr)
--- 8,12 ----
! == 482 tests, 11 stderr failures, 1 stdout failure, 0 post failures ==
memcheck/tests/origin5-bz2 (stderr)
+ lackey/tests/true (stderr)
none/tests/empty-exe (stderr)
***************
*** 17,18 ****
--- 18,20 ----
none/tests/shell_zerolength (stderr)
+ helgrind/tests/pth_barrier3 (stderr)
helgrind/tests/tc06_two_races_xml (stderr)
=================================================
./valgrind-new/exp-ptrcheck/tests/supp.stderr.diff
=================================================
--- supp.stderr.exp 2009-08-06 03:10:52.000000000 +1000
+++ supp.stderr.out 2009-08-06 03:20:52.000000000 +1000
@@ -1,7 +1,7 @@
Syscall param write(buf) is non-contiguous
- at 0x........: write (in /...libc...)
- by 0x........: main (supp.c:16)
+ at 0x........: ??? (in /lib32/ld-2.9.so)
+ by 0x........: (below main)
First byte (0x........) is 3 bytes inside a 6-byte block alloc'd
at 0x........: malloc (vg_replace_malloc.c:...)
by 0x........: main (supp.c:12)
=================================================
./valgrind-new/helgrind/tests/pth_barrier3.stderr.diff
=================================================
--- pth_barrier3.stderr.exp 2009-08-06 03:10:48.000000000 +1000
+++ pth_barrier3.stderr.out 2009-08-06 03:18:19.000000000 +1000
@@ -18,3 +18,26 @@
at 0x........: threadfunc (pth_barrier.c:57)
by 0x........: mythread_wrapper (hg_intercepts.c:...)
...
+
+Thread #x was created
+ ...
+ by 0x........: pthread_create@* (hg_intercepts.c:...)
+ by 0x........: barriers_and_races (pth_barrier.c:84)
+ by 0x........: main (pth_barrier.c:107)
+
+Thread #x was created
+ ...
+ by 0x........: pthread_create@* (hg_intercepts.c:...)
+ by 0x........: barriers_and_races (pth_barrier.c:84)
+ by 0x........: main (pth_barrier.c:107)
+
+Possible data race during read of size 4 at 0x........ by thread #x
+ at 0x........: ??? (in /lib32/ld-2.9.so)
+ by 0x........: threadfunc (pth_barrier.c:58)
+ by 0x........: mythread_wrapper (hg_intercepts.c:...)
+ ...
+ This conflicts with a previous write of size 4 by thread #x
+ at 0x........: pthread_barrier_wait (in /...libpthread...)
+ by 0x........: threadfunc (pth_barrier.c:58)
+ by 0x........: mythread_wrapper (hg_intercepts.c:...)
+ ...
=================================================
./valgrind-new/helgrind/tests/tc06_two_races_xml.stderr.diff
=================================================
--- tc06_two_races_xml.stderr.exp 2009-08-06 03:10:48.000000000 +1000
+++ tc06_two_races_xml.stderr.out 2009-08-06 03:18:24.000000000 +1000
@@ -44,16 +44,6 @@
<frame>
<ip>0x........</ip>
<obj>...</obj>
- <fn>do_clone</fn>
- </frame>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
- <fn>pthread_create@@GLIBC_2.2.5</fn>
- </frame>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
<fn>pthread_create_WRK</fn>
<dir>...</dir>
<file>hg_intercepts.c</file>
=================================================
./valgrind-new/lackey/tests/true.stderr.diff
=================================================
--- true.stderr.exp 2009-08-06 03:11:37.000000000 +1000
+++ true.stderr.out 2009-08-06 03:17:04.000000000 +1000
@@ -1,6 +1,6 @@
-Counted ... calls to _dl_runtime_resolve()
+Counted ... call to main()
Jccs:
total: ...
=================================================
./valgrind-new/memcheck/tests/origin5-bz2.stderr.diff-glibc25-amd64
=================================================
--- origin5-bz2.stderr.exp-glibc25-amd64 2009-08-06 03:11:09.000000000 +1000
+++ origin5-bz2.stderr.out 2009-08-06 03:15:59.000000000 +1000
@@ -11,7 +11,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: handle_compress (origin5-bz2.c:4686)
by 0x........: BZ2_bzCompress (origin5-bz2.c:4822)
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
@@ -19,7 +19,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: handle_compress (origin5-bz2.c:4686)
by 0x........: BZ2_bzCompress (origin5-bz2.c:4822)
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
@@ -27,7 +27,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: mainSort (origin5-bz2.c:2820)
by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -38,7 +38,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: mainSort (origin5-bz2.c:2823)
by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -49,7 +49,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: mainSort (origin5-bz2.c:2854)
by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -60,7 +60,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: mainSort (origin5-bz2.c:2858)
by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -71,7 +71,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: mainSort (origin5-bz2.c:2963)
by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -82,7 +82,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: mainSort (origin5-bz2.c:2964)
by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -93,7 +93,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: fallbackSort (origin5-bz2.c:2269)
by 0x........: BZ2_blockSort (origin5-bz2.c:3116)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -104,7 +104,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: fallbackSort (origin5-bz2.c:2275)
by 0x........: BZ2_blockSort (origin5-bz2.c:3116)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
=================================================
./valgrind-new/memcheck/tests/origin5-bz2.stderr.diff-glibc25-x86
=================================================
--- origin5-bz2.stderr.exp-glibc25-x86 2009-08-06 03:11:09.000000000 +1000
+++ origin5-bz2.stderr.out 2009-08-06 03:15:59.000000000 +1000
@@ -28,7 +28,8 @@
at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 4
- at 0x........: BZ2_blockSort (origin5-bz2.c:2820)
+ at 0x........: mainSort (origin5-bz2.c:2820)
+ by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
by 0x........: handle_compress (origin5-bz2.c:4753)
by 0x........: BZ2_bzCompress (origin5-bz2.c:4822)
@@ -38,7 +39,8 @@
at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 4
- at 0x........: BZ2_blockSort (origin5-bz2.c:2823)
+ at 0x........: mainSort (origin5-bz2.c:2823)
+ by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
by 0x........: handle_compress (origin5-bz2.c:4753)
by 0x........: BZ2_bzCompress (origin5-bz2.c:4822)
@@ -48,7 +50,8 @@
at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 4
- at 0x........: BZ2_blockSort (origin5-bz2.c:2855)
+ at 0x........: mainSort (origin5-bz2.c:2854)
+ by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
by 0x........: handle_compress (origin5-bz2.c:4753)
by 0x........: BZ2_bzCompress (origin5-bz2.c:4822)
@@ -58,7 +61,8 @@
at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 4
- at 0x........: BZ2_blockSort (origin5-bz2.c:2859)
+ at 0x........: mainSort (origin5-bz2.c:2858)
+ by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
by 0x........: handle_compress (origin5-bz2.c:4753)
by 0x........: BZ2_bzCompress (origin5-bz2.c:4822)
@@ -68,7 +72,8 @@
at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 4
- at 0x........: BZ2_blockSort (origin5-bz2.c:2963)
+ at 0x........: mainSort (origin5-bz2.c:2963)
+ by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
by 0x........: handle_compress (origin5-bz2.c:4753)
by 0x........: BZ2_bzCompress (origin5-bz2.c:4822)
@@ -78,7 +83,8 @@
at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 4
- at 0x........: BZ2_blockSort (origin5-bz2.c:2964)
+ at 0x........: mainSort (origin5-bz2.c:2964)
+ by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
by 0x........: handle_compress (origin5-bz2.c:4753)
by 0x........: BZ2_bzCompress (origin5-bz2.c:4822)
=================================================
./valgrind-new/memcheck/tests/origin5-bz2.stderr.diff-glibc27-ppc64
=================================================
--- origin5-bz2.stderr.exp-glibc27-ppc64 2009-08-06 03:11:09.000000000 +1000
+++ origin5-bz2.stderr.out 2009-08-06 03:15:59.000000000 +1000
@@ -1,7 +1,7 @@
Conditional jump or move depends on uninitialised value(s)
at 0x........: main (origin5-bz2.c:6481)
Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6481)
+ at 0x........: main (origin5-bz2.c:6479)
Conditional jump or move depends on uninitialised value(s)
at 0x........: handle_compress (origin5-bz2.c:4686)
@@ -9,85 +9,91 @@
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
by 0x........: main (origin5-bz2.c:6484)
Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6481)
+ at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: handle_compress (origin5-bz2.c:4686)
by 0x........: BZ2_bzCompress (origin5-bz2.c:4822)
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
by 0x........: main (origin5-bz2.c:6484)
Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6481)
+ at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: handle_compress (origin5-bz2.c:4686)
by 0x........: BZ2_bzCompress (origin5-bz2.c:4822)
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
by 0x........: main (origin5-bz2.c:6484)
Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6481)
+ at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
- at 0x........: BZ2_blockSort (origin5-bz2.c:2820)
+Use of uninitialised value of size 4
+ at 0x........: mainSort (origin5-bz2.c:2820)
+ by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
by 0x........: handle_compress (origin5-bz2.c:4753)
by 0x........: BZ2_bzCompress (origin5-bz2.c:4822)
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
by 0x........: main (origin5-bz2.c:6484)
Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6481)
+ at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
- at 0x........: BZ2_blockSort (origin5-bz2.c:2823)
+Use of uninitialised value of size 4
+ at 0x........: mainSort (origin5-bz2.c:2823)
+ by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
by 0x........: handle_compress (origin5-bz2.c:4753)
by 0x........: BZ2_bzCompress (origin5-bz2.c:4822)
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
by 0x........: main (origin5-bz2.c:6484)
Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6481)
+ at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
- at 0x........: BZ2_blockSort (origin5-bz2.c:2854)
+Use of uninitialised value of size 4
+ at 0x........: mainSort (origin5-bz2.c:2854)
+ by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
by 0x........: handle_compress (origin5-bz2.c:4753)
by 0x........: BZ2_bzCompress (origin5-bz2.c:4822)
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
by 0x........: main (origin5-bz2.c:6484)
Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6481)
+ at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
- at 0x........: BZ2_blockSort (origin5-bz2.c:2858)
+Use of uninitialised value of size 4
+ at 0x........: mainSort (origin5-bz2.c:2858)
+ by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
by 0x........: handle_compress (origin5-bz2.c:4753)
by 0x........: BZ2_bzCompress (origin5-bz2.c:4822)
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
by 0x........: main (origin5-bz2.c:6484)
Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6481)
+ at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
- at 0x........: BZ2_blockSort (origin5-bz2.c:2963)
+Use of uninitialised value of size 4
+ at 0x........: mainSort (origin5-bz2.c:2963)
+ by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
<truncated beyond 100 lines>
=================================================
./valgrind-new/none/tests/empty-exe.stderr.diff
=================================================
--- empty-exe.stderr.exp 2009-08-06 03:11:37.000000000 +1000
+++ empty-exe.stderr.out 2009-08-06 03:17:18.000000000 +1000
@@ -1,2 +1,2 @@
-
-
+valgrind: wrong ELF executable class (eg. 32-bit instead of 64-bit)
+valgrind: ./empty-exe: bad interpreter (/bin/sh): VG_(strerror): unknown error
=================================================
./valgrind-new/none/tests/shell.stderr.diff
=================================================
--- shell.stderr.exp 2009-08-06 03:11:36.000000000 +1000
+++ shell.stderr.out 2009-08-06 03:17:39.000000000 +1000
@@ -1,8 +1,3 @@
-./shell: ./x86/: is a directory
-./shell: ./shell.vgtest: Permission denied
-execve(0x........(./shell_badinterp), 0x........, 0x........) failed, errno 2
-EXEC FAILED: I can't recover from execve() failing, so I'm dying.
-Add more stringent tests in PRE(sys_execve), or work out how to recover.
-./shell: ./shell_binaryfile: cannot execute binary file
-./shell: ./shell_nosuchfile: No such file or directory
-./shell: shell_nosuchfile: command not found
+valgrind: wrong ELF executable class (eg. 32-bit instead of 64-bit)
+valgrind: wrong ELF executable class (eg. 32-bit instead of 64-bit)
+valgrind: ./shell: bad interpreter (/bin/sh): VG_(strerror): unknown error
=================================================
./valgrind-new/none/tests/shell.stderr.diff-dash
=================================================
--- shell.stderr.exp-dash 2009-08-06 03:11:36.000000000 +1000
+++ shell.stderr.out 2009-08-06 03:17:39.000000000 +1000
@@ -1,8 +1,3 @@
-./shell: 10: ./x86/: Permission denied
-./shell: 13: ./shell.vgtest: Permission denied
-execve(0x........(./shell_badinterp), 0x........, 0x........) failed, errno 2
-EXEC FAILED: I can't recover from execve() failing, so I'm dying.
-Add more stringent tests in PRE(sys_execve), or work out how to recover.
-./shell_binaryfile: 4: Syntax error: ")" unexpected
-./shell: 22: ./shell_nosuchfile: not found
-./shell: 25: shell_nosuchfile: not found
+valgrind: wrong ELF executable class (eg. 32-bit instead of 64-bit)
+valgrind: wrong ELF executable class (eg. 32-bit instead of 64-bit)
+valgrind: ./shell: bad interpreter (/bin/sh): VG_(strerror): unknown error
=================================================
./valgrind-new/none/tests/shell.stdout.diff
=================================================
--- shell.stdout.exp 2009-08-06 03:11:36.000000000 +1000
+++ shell.stdout.out 2009-08-06 03:17:39.000000000 +1000
@@ -1,10 +0,0 @@
-Execute a directory
-Execute a non-executable file
-Execute a script with a bad interpreter name
-Execute a binary file
-Execute a non-existent file
-Execute a non-existent file (2)
-Execute a valid script with a #! line
-Execute a valid script without a #! line
-Execute a valid script with #! but no interpname
-Execute a zero-length file
=================================================
./valgrind-new/none/tests/shell_valid1.stderr.diff
=================================================
--- shell_valid1.stderr.exp 2009-08-06 03:11:36.000000000 +1000
+++ shell_valid1.stderr.out 2009-08-06 03:17:40.000000000 +1000
@@ -0,0 +1,3 @@
+valgrind: wrong ELF executable class (eg. 32-bit instead of 64-bit)
+valgrind: wrong ELF executable class (eg. 32-bit instead of 64-bit)
+valgrind: ./shell_valid1: bad interpreter (/bin/sh): VG_(strerror): unknown error
=================================================
./valgrind-new/none/tests/shell_valid2.stderr.diff
=================================================
--- shell_valid2.stderr.exp 2009-08-06 03:11:36.000000000 +1000
+++ shell_valid2.stderr.out 2009-08-06 03:17:40.000000000 +1000
@@ -0,0 +1,2 @@
+valgrind: wrong ELF executable class (eg. 32-bit instead of 64-bit)
+valgrind: ./shell_valid2: bad interpreter (/bin/sh): VG_(strerror): unknown error
=================================================
./valgrind-new/none/tests/shell_valid3.stderr.diff
=================================================
--- shell_valid3.stderr.exp 2009-08-06 03:11:37.000000000 +1000
+++ shell_valid3.stderr.out 2009-08-06 03:17:40.000000000 +1000
@@ -0,0 +1,2 @@
+valgrind: wrong ELF executable class (eg. 32-bit instead of 64-bit)
+valgrind: ./shell_valid3: bad interpreter (/bin/sh): VG_(strerror): unknown error
=================================================
./valgrind-new/none/tests/shell_zerolength.stderr.diff
=================================================
--- shell_zerolength.stderr.exp 2009-08-06 03:11:36.000000000 +1000
+++ shell_zerolength.stderr.out 2009-08-06 03:17:40.000000000 +1000
@@ -0,0 +1,2 @@
+valgrind: wrong ELF executable class (eg. 32-bit instead of 64-bit)
+valgrind: ./shell_zerolength: bad interpreter (/bin/sh): VG_(strerror): unknown error
=================================================
./valgrind-new/none/tests/shell_zerolength.stderr.diff-dash
=================================================
--- shell_zerolength.stderr.exp-dash 2009-08-06 03:11:36.000000000 +1000
+++ shell_zerolength.stderr.out 2009-08-06 03:17:40.000000000 +1000
@@ -1 +1,2 @@
-Bus error
+valgrind: wrong ELF executable class (eg. 32-bit instead of 64-bit)
+valgrind: ./shell_zerolength: bad interpreter (/bin/sh): VG_(strerror): unknown error
=================================================
./valgrind-old/exp-ptrcheck/tests/supp.stderr.diff
=================================================
--- supp.stderr.exp 2009-08-06 03:00:32.000000000 +1000
+++ supp.stderr.out 2009-08-06 03:10:29.000000000 +1000
@@ -1,7 +1,7 @@
Syscall param write(buf) is non-contiguous
- at 0x........: write (in /...libc...)
- by 0x........: main (supp.c:16)
+ at 0x........: ??? (in /lib32/ld-2.9.so)
+ by 0x........: (below main)
First byte (0x........) is 3 bytes inside a 6-byte block alloc'd
at 0x........: malloc (vg_replace_malloc.c:...)
by 0x........: main (supp.c:12)
=================================================
./valgrind-old/helgrind/tests/tc06_two_races_xml.stderr.diff
=================================================
--- tc06_two_races_xml.stderr.exp 2009-08-06 03:00:29.000000000 +1000
+++ tc06_two_races_xml.stderr.out 2009-08-06 03:08:02.000000000 +1000
@@ -44,16 +44,6 @@
<frame>
<ip>0x........</ip>
<obj>...</obj>
- <fn>do_clone</fn>
- </frame>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
- <fn>pthread_create@@GLIBC_2.2.5</fn>
- </frame>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
<fn>pthread_create_WRK</fn>
<dir>...</dir>
<file>hg_intercepts.c</file>
=================================================
./valgrind-old/memcheck/tests/origin5-bz2.stderr.diff-glibc25-amd64
=================================================
--- origin5-bz2.stderr.exp-glibc25-amd64 2009-08-06 03:00:49.000000000 +1000
+++ origin5-bz2.stderr.out 2009-08-06 03:05:36.000000000 +1000
@@ -11,7 +11,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: handle_compress (origin5-bz2.c:4686)
by 0x........: BZ2_bzCompress (origin5-bz2.c:4822)
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
@@ -19,7 +19,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: handle_compress (origin5-bz2.c:4686)
by 0x........: BZ2_bzCompress (origin5-bz2.c:4822)
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
@@ -27,7 +27,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: mainSort (origin5-bz2.c:2820)
by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -38,7 +38,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: mainSort (origin5-bz2.c:2823)
by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -49,7 +49,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: mainSort (origin5-bz2.c:2854)
by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -60,7 +60,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: mainSort (origin5-bz2.c:2858)
by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -71,7 +71,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: mainSort (origin5-bz2.c:2963)
by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -82,7 +82,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: mainSort (origin5-bz2.c:2964)
by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -93,7 +93,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: fallbackSort (origin5-bz2.c:2269)
by 0x........: BZ2_blockSort (origin5-bz2.c:3116)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -104,7 +104,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: fallbackSort (origin5-bz2.c:2275)
by 0x........: BZ2_blockSort (origin5-bz2.c:3116)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
=================================================
./valgrind-old/memcheck/tests/origin5-bz2.stderr.diff-glibc25-x86
=================================================
--- origin5-bz2.stderr.exp-glibc25-x86 2009-08-06 03:00:50.000000000 +1000
+++ origin5-bz2.stderr.out 2009-08-06 03:05:36.000000000 +1000
@@ -28,7 +28,8 @@
at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 4
- at 0x........: BZ2_blockSort (origin5-bz2.c:2820)
+ at 0x........: mainSort (origin5-bz2.c:2820)
+ by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
by 0x........: handle_compress (origin5-bz2.c:4753)
by 0x........: BZ2_bzCompress (origin5-bz2.c:4822)
@@ -38,7 +39,8 @@
at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 4
- at 0x........: BZ2_blockSort (origin5-bz2.c:2823)
+ at 0x........: mainSort (origin5-bz2.c:2823)
+ by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
by 0x........: handle_compress (origin5-bz2.c:4753)
by 0x........: BZ2_bzCompress (origin5-bz2.c:4822)
@@ -48,7 +50,8 @@
at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 4
- at 0x........: BZ2_blockSort (origin5-bz2.c:2855)
+ at 0x........: mainSort (origin5-bz2.c:2854)
+ by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
by 0x........: handle_compress (origin5-bz2.c:4753)
by 0x........: BZ2_bzCompress (origin5-bz2.c:4822)
@@ -58,7 +61,8 @@
at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 4
- at 0x........: BZ2_blockSort (origin5-bz2.c:2859)
+ at 0x........: mainSort (origin5-bz2.c:2858)
+ by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
by 0x........: handle_compress (origin5-bz2.c:4753)
by 0x........: BZ2_bzCompress (origin5-bz2.c:4822)
@@ -68,7 +72,8 @@
at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 4
- at 0x........: BZ2_blockSort (origin5-bz2.c:2963)
+ at 0x........: mainSort (origin5-bz2.c:2963)
+ by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
by 0x........: handle_compress (origin5-bz2.c:4753)
by 0x........: BZ2_bzCompress (origin5-bz2.c:4822)
@@ -78,7 +83,8 @@
at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 4
- at 0x........: BZ2_blockSort (origin5-bz2.c:2964)
+ at 0x........: mainSort (origin5-bz2.c:2964)
+ by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
by 0x........: handle_compress (origin5-bz2.c:4753)
by 0x........: BZ2_bzCompress (origin5-bz2.c:4822)
=================================================
./valgrind-old/memcheck/tests/origin5-bz2.stderr.diff-glibc27-ppc64
=================================================
--- origin5-bz2.stderr.exp-glibc27-ppc64 2009-08-06 03:00:49.000000000 +1000
+++ origin5-bz2.stderr.out 2009-08-06 03:05:36.000000000 +1000
@@ -1,7 +1,7 @@
Conditional jump or move depends on uninitialised value(s)
at 0x........: main (origin5-bz2.c:6481)
Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6481)
+ at 0x........: main (origin5-bz2.c:6479)
Conditional jump or move depends on uninitialised value(s)
at 0x........: handle_compress (origin5-bz2.c:4686)
@@ -9,85 +9,91 @@
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
by 0x........: main (origin5-bz2.c:6484)
Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6481)
+ at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: handle_compress (origin5-bz2.c:4686)
by 0x........: BZ2_bzCompress (origin5-bz2.c:4822)
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
by 0x........: main (origin5-bz2.c:6484)
Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6481)
+ at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: handle_compress (origin5-bz2.c:4686)
by 0x........: BZ2_bzCompress (origin5-bz2.c:4822)
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
by 0x........: main (origin5-bz2.c:6484)
Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6481)
+ at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
- at 0x........: BZ2_blockSort (origin5-bz2.c:2820)
+Use of uninitialised value of size 4
+ at 0x........: mainSort (origin5-bz2.c:2820)
+ by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
by 0x........: handle_compress (origin5-bz2.c:4753)
by 0x........: BZ2_bzCompress (origin5-bz2.c:4822)
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
by 0x........: main (origin5-bz2.c:6484)
Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6481)
+ at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
- at 0x........: BZ2_blockSort (origin5-bz2.c:2823)
+Use of uninitialised value of size 4
+ at 0x........: mainSort (origin5-bz2.c:2823)
+ by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
by 0x........: handle_compress (origin5-bz2.c:4753)
by 0x........: BZ2_bzCompress (origin5-bz2.c:4822)
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
by 0x........: main (origin5-bz2.c:6484)
Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6481)
+ at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
- at 0x........: BZ2_blockSort (origin5-bz2.c:2854)
+Use of uninitialised value of size 4
+ at 0x........: mainSort (origin5-bz2.c:2854)
+ by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
by 0x........: handle_compress (origin5-bz2.c:4753)
by 0x........: BZ2_bzCompress (origin5-bz2.c:4822)
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
by 0x........: main (origin5-bz2.c:6484)
Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6481)
+ at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
- at 0x........: BZ2_blockSort (origin5-bz2.c:2858)
+Use of uninitialised value of size 4
+ at 0x........: mainSort (origin5-bz2.c:2858)
+ by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
by 0x........: handle_compress (origin5-bz2.c:4753)
by 0x........: BZ2_bzCompress (origin5-bz2.c:4822)
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
by 0x........: main (origin5-bz2.c:6484)
Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6481)
+ at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
- at 0x........: BZ2_blockSort (origin5-bz2.c:2963)
+Use of uninitialised value of size 4
+ at 0x........: mainSort (origin5-bz2.c:2963)
+ by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
<truncated beyond 100 lines>
=================================================
./valgrind-old/none/tests/empty-exe.stderr.diff
=================================================
--- empty-exe.stderr.exp 2009-08-06 03:01:14.000000000 +1000
+++ empty-exe.stderr.out 2009-08-06 03:06:56.000000000 +1000
@@ -1,2 +1,2 @@
-
-
+valgrind: wrong ELF executable class (eg. 32-bit instead of 64-bit)
+valgrind: ./empty-exe: bad interpreter (/bin/sh): VG_(strerror): unknown error
=================================================
./valgrind-old/none/tests/shell.stderr.diff
=================================================
--- shell.stderr.exp 2009-08-06 03:01:14.000000000 +1000
+++ shell.stderr.out 2009-08-06 03:07:18.000000000 +1000
@@ -1,8 +1,3 @@
-./shell: ./x86/: is a directory
-./shell: ./shell.vgtest: Permission denied
-execve(0x........(./shell_badinterp), 0x........, 0x........) failed, errno 2
-EXEC FAILED: I can't recover from execve() failing, so I'm dying.
-Add more stringent tests in PRE(sys_execve), or work out how to recover.
-./shell: ./shell_binaryfile: cannot execute binary file
-./shell: ./shell_nosuchfile: No such file or directory
-./shell: shell_nosuchfile: command not found
+valgrind: wrong ELF executable class (eg. 32-bit instead of 64-bit)
+valgrind: wrong ELF executable class (eg. 32-bit instead of 64-bit)
+valgrind: ./shell: bad interpreter (/bin/sh): VG_(strerror): unknown error
=================================================
./valgrind-old/none/tests/shell.stderr.diff-dash
=================================================
--- shell.stderr.exp-dash 2009-08-06 03:01:14.000000000 +1000
+++ shell.stderr.out 2009-08-06 03:07:18.000000000 +1000
@@ -1,8 +1,3 @@
-./shell: 10: ./x86/: Permission denied
-./shell: 13: ./shell.vgtest: Permission denied
-execve(0x........(./shell_badinterp), 0x........, 0x........) failed, errno 2
-EXEC FAILED: I can't recover from execve() failing, so I'm dying.
-Add more stringent tests in PRE(sys_execve), or work out how to recover.
-./shell_binaryfile: 4: Syntax error: ")" unexpected
-./shell: 22: ./shell_nosuchfile: not found
-./shell: 25: shell_nosuchfile: not found
+valgrind: wrong ELF executable class (eg. 32-bit instead of 64-bit)
+valgrind: wrong ELF executable class (eg. 32-bit instead of 64-bit)
+valgrind: ./shell: bad interpreter (/bin/sh): VG_(strerror): unknown error
=================================================
./valgrind-old/none/tests/shell.stdout.diff
=================================================
--- shell.stdout.exp 2009-08-06 03:01:14.000000000 +1000
+++ shell.stdout.out 2009-08-06 03:07:18.000000000 +1000
@@ -1,10 +0,0 @@
-Execute a directory
-Execute a non-executable file
-Execute a script with a bad interpreter name
-Execute a binary file
-Execute a non-existent file
-Execute a non-existent file (2)
-Execute a valid script with a #! line
-Execute a valid script without a #! line
-Execute a valid script with #! but no interpname
-Execute a zero-length file
=================================================
./valgrind-old/none/tests/shell_valid1.stderr.diff
=================================================
--- shell_valid1.stderr.exp 2009-08-06 03:01:14.000000000 +1000
+++ shell_valid1.stderr.out 2009-08-06 03:07:18.000000000 +1000
@@ -0,0 +1,3 @@
+valgrind: wrong ELF executable class (eg. 32-bit instead of 64-bit)
+valgrind: wrong ELF executable class (eg. 32-bit instead of 64-bit)
+valgrind: ./shell_valid1: bad interpreter (/bin/sh): VG_(strerror): unknown error
=================================================
./valgrind-old/none/tests/shell_valid2.stderr.diff
=================================================
--- shell_valid2.stderr.exp 2009-08-06 03:01:14.000000000 +1000
+++ shell_valid2.stderr.out 2009-08-06 03:07:18.000000000 +1000
@@ -0,0 +1,2 @@
+valgrind: wrong ELF executable class (eg. 32-bit instead of 64-bit)
+valgrind: ./shell_valid2: bad interpreter (/bin/sh): VG_(strerror): unknown error
=================================================
./valgrind-old/none/tests/shell_valid3.stderr.diff
=================================================
--- shell_valid3.stderr.exp 2009-08-06 03:01:14.000000000 +1000
+++ shell_valid3.stderr.out 2009-08-06 03:07:18.000000000 +1000
@@ -0,0 +1,2 @@
+valgrind: wrong ELF executable class (eg. 32-bit instead of 64-bit)
+valgrind: ./shell_valid3: bad interpreter (/bin/sh): VG_(strerror): unknown error
=================================================
./valgrind-old/none/tests/shell_zerolength.stderr.diff
=================================================
--- shell_zerolength.stderr.exp 2009-08-06 03:01:14.000000000 +1000
+++ shell_zerolength.stderr.out 2009-08-06 03:07:18.000000000 +1000
@@ -0,0 +1,2 @@
+valgrind: wrong ELF executable class (eg. 32-bit instead of 64-bit)
+valgrind: ./shell_zerolength: bad interpreter (/bin/sh): VG_(strerror): unknown error
=================================================
./valgrind-old/none/tests/shell_zerolength.stderr.diff-dash
=================================================
--- shell_zerolength.stderr.exp-dash 2009-08-06 03:01:14.000000000 +1000
+++ shell_zerolength.stderr.out 2009-08-06 03:07:18.000000000 +1000
@@ -1 +1,2 @@
-Bus error
+valgrind: wrong ELF executable class (eg. 32-bit instead of 64-bit)
+valgrind: ./shell_zerolength: bad interpreter (/bin/sh): VG_(strerror): unknown error
|
|
From: xiaoming gu <xia...@gm...> - 2009-08-05 16:38:00
|
Hi, all. Does anyone know the purpose of the first argument for VG_(malloc)? The function is with the prototype "extern void* VG_(malloc)(HChar* cc, SizeT nbytes);". I checked the available tools and only found some magic strings such as "mc.acb.1". Thanks. Xiaoming |
|
From: Nicholas N. <n.n...@gm...> - 2009-08-05 16:24:38
|
Nightly build on ocean ( Ubuntu 9.04, x86_64 )
Started at 2009-08-06 02:00:01 EST
Ended at 2009-08-06 02:24:25 EST
Results differ from 24 hours ago
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... done
Running regression tests ... failed
Regression test results follow
== 526 tests, 2 stderr failures, 0 stdout failures, 0 post failures ==
lackey/tests/true (stderr)
helgrind/tests/tc06_two_races_xml (stderr)
=================================================
== Results from 24 hours ago ==
=================================================
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... done
Running regression tests ... failed
Regression test results follow
== 526 tests, 1 stderr failure, 0 stdout failures, 0 post failures ==
helgrind/tests/tc06_two_races_xml (stderr)
=================================================
== Difference between 24 hours ago and now ==
=================================================
*** old.short Thu Aug 6 02:12:04 2009
--- new.short Thu Aug 6 02:24:25 2009
***************
*** 8,10 ****
! == 526 tests, 1 stderr failure, 0 stdout failures, 0 post failures ==
helgrind/tests/tc06_two_races_xml (stderr)
--- 8,11 ----
! == 526 tests, 2 stderr failures, 0 stdout failures, 0 post failures ==
! lackey/tests/true (stderr)
helgrind/tests/tc06_two_races_xml (stderr)
=================================================
./valgrind-new/helgrind/tests/tc06_two_races_xml.stderr.diff
=================================================
--- tc06_two_races_xml.stderr.exp 2009-08-06 02:12:22.000000000 +1000
+++ tc06_two_races_xml.stderr.out 2009-08-06 02:22:06.000000000 +1000
@@ -44,11 +44,6 @@
<frame>
<ip>0x........</ip>
<obj>...</obj>
- <fn>do_clone</fn>
- </frame>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
<fn>pthread_create@@GLIBC_2.2.5</fn>
</frame>
<frame>
=================================================
./valgrind-new/lackey/tests/true.stderr.diff
=================================================
--- true.stderr.exp 2009-08-06 02:13:11.000000000 +1000
+++ true.stderr.out 2009-08-06 02:20:13.000000000 +1000
@@ -1,6 +1,6 @@
-Counted ... calls to _dl_runtime_resolve()
+Counted ... call to main()
Jccs:
total: ...
=================================================
./valgrind-old/helgrind/tests/tc06_two_races_xml.stderr.diff
=================================================
--- tc06_two_races_xml.stderr.exp 2009-08-06 02:00:25.000000000 +1000
+++ tc06_two_races_xml.stderr.out 2009-08-06 02:09:49.000000000 +1000
@@ -44,11 +44,6 @@
<frame>
<ip>0x........</ip>
<obj>...</obj>
- <fn>do_clone</fn>
- </frame>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
<fn>pthread_create@@GLIBC_2.2.5</fn>
</frame>
<frame>
|
|
From: <sv...@va...> - 2009-08-05 08:08:30
|
Author: njn
Date: 2009-08-05 09:08:18 +0100 (Wed, 05 Aug 2009)
New Revision: 10721
Log:
More docs build tweaks:
- Actually remove the dead docs/images/massif*.png files (this was meant to
happen in r10720).
- Inline $TOOL/docs/Makefile.am into $TOOL/Makefile.am for all 10 tools. 10
fewer Makefile.am files FTW!
Removed:
trunk/cachegrind/docs/Makefile.am
trunk/callgrind/docs/Makefile.am
trunk/docs/images/massif-graph-sm.png
trunk/docs/images/massif-graph.png
trunk/drd/docs/Makefile.am
trunk/exp-bbv/docs/Makefile.am
trunk/exp-ptrcheck/docs/Makefile.am
trunk/helgrind/docs/Makefile.am
trunk/lackey/docs/Makefile.am
trunk/massif/docs/Makefile.am
trunk/memcheck/docs/Makefile.am
trunk/none/docs/Makefile.am
Modified:
trunk/Makefile.tool.am
trunk/cachegrind/Makefile.am
trunk/callgrind/Makefile.am
trunk/configure.in
trunk/drd/Makefile.am
trunk/exp-bbv/Makefile.am
trunk/exp-ptrcheck/Makefile.am
trunk/helgrind/Makefile.am
trunk/lackey/Makefile.am
trunk/massif/Makefile.am
trunk/memcheck/Makefile.am
trunk/none/Makefile.am
Modified: trunk/Makefile.tool.am
===================================================================
--- trunk/Makefile.tool.am 2009-08-05 07:39:45 UTC (rev 10720)
+++ trunk/Makefile.tool.am 2009-08-05 08:08:18 UTC (rev 10721)
@@ -1,5 +1,5 @@
-SUBDIRS = . tests docs
+SUBDIRS = . tests
include $(top_srcdir)/Makefile.all.am
Modified: trunk/cachegrind/Makefile.am
===================================================================
--- trunk/cachegrind/Makefile.am 2009-08-05 07:39:45 UTC (rev 10720)
+++ trunk/cachegrind/Makefile.am 2009-08-05 08:08:18 UTC (rev 10721)
@@ -1,5 +1,7 @@
include $(top_srcdir)/Makefile.tool.am
+EXTRA_DIST = docs/cg-manual.xml
+
#----------------------------------------------------------------------------
# Headers, etc
#----------------------------------------------------------------------------
Deleted: trunk/cachegrind/docs/Makefile.am
===================================================================
--- trunk/cachegrind/docs/Makefile.am 2009-08-05 07:39:45 UTC (rev 10720)
+++ trunk/cachegrind/docs/Makefile.am 2009-08-05 08:08:18 UTC (rev 10721)
@@ -1 +0,0 @@
-EXTRA_DIST = cg-manual.xml
Modified: trunk/callgrind/Makefile.am
===================================================================
--- trunk/callgrind/Makefile.am 2009-08-05 07:39:45 UTC (rev 10720)
+++ trunk/callgrind/Makefile.am 2009-08-05 08:08:18 UTC (rev 10721)
@@ -1,5 +1,13 @@
include $(top_srcdir)/Makefile.tool.am
+EXTRA_DIST = \
+ docs/cl-entities.xml \
+ docs/cl-manual.xml \
+ docs/cl-format.xml \
+ docs/man-annotate.xml \
+ docs/man-control.xml \
+ docs/man-callgrind.xml
+
#----------------------------------------------------------------------------
# Headers, etc
#----------------------------------------------------------------------------
Deleted: trunk/callgrind/docs/Makefile.am
===================================================================
--- trunk/callgrind/docs/Makefile.am 2009-08-05 07:39:45 UTC (rev 10720)
+++ trunk/callgrind/docs/Makefile.am 2009-08-05 08:08:18 UTC (rev 10721)
@@ -1,7 +0,0 @@
-EXTRA_DIST = \
- cl-entities.xml \
- cl-manual.xml \
- cl-format.xml \
- man-annotate.xml \
- man-control.xml \
- man-callgrind.xml
Modified: trunk/configure.in
===================================================================
--- trunk/configure.in 2009-08-05 07:39:45 UTC (rev 10720)
+++ trunk/configure.in 2009-08-05 08:08:18 UTC (rev 10721)
@@ -1858,28 +1858,22 @@
memcheck/tests/darwin/Makefile
memcheck/tests/x86-linux/Makefile
memcheck/perf/Makefile
- memcheck/docs/Makefile
cachegrind/Makefile
cachegrind/tests/Makefile
cachegrind/tests/x86/Makefile
- cachegrind/docs/Makefile
cachegrind/cg_annotate
callgrind/Makefile
callgrind/callgrind_annotate
callgrind/callgrind_control
callgrind/tests/Makefile
- callgrind/docs/Makefile
helgrind/Makefile
helgrind/tests/Makefile
- helgrind/docs/Makefile
massif/Makefile
massif/tests/Makefile
massif/perf/Makefile
- massif/docs/Makefile
massif/ms_print
lackey/Makefile
lackey/tests/Makefile
- lackey/docs/Makefile
none/Makefile
none/tests/Makefile
none/tests/amd64/Makefile
@@ -1889,16 +1883,12 @@
none/tests/linux/Makefile
none/tests/darwin/Makefile
none/tests/x86-linux/Makefile
- none/docs/Makefile
exp-ptrcheck/Makefile
exp-ptrcheck/tests/Makefile
- exp-ptrcheck/docs/Makefile
drd/Makefile
- drd/docs/Makefile
drd/scripts/download-and-build-splash2
drd/tests/Makefile
exp-bbv/Makefile
- exp-bbv/docs/Makefile
exp-bbv/tests/Makefile
exp-bbv/tests/x86/Makefile
exp-bbv/tests/x86-linux/Makefile
Deleted: trunk/docs/images/massif-graph-sm.png
===================================================================
(Binary files differ)
Deleted: trunk/docs/images/massif-graph.png
===================================================================
(Binary files differ)
Modified: trunk/drd/Makefile.am
===================================================================
--- trunk/drd/Makefile.am 2009-08-05 07:39:45 UTC (rev 10720)
+++ trunk/drd/Makefile.am 2009-08-05 08:08:18 UTC (rev 10721)
@@ -1,5 +1,7 @@
include $(top_srcdir)/Makefile.tool.am
+EXTRA_DIST = docs/drd-manual.xml
+
#----------------------------------------------------------------------------
# Headers, flags
#----------------------------------------------------------------------------
Deleted: trunk/drd/docs/Makefile.am
===================================================================
--- trunk/drd/docs/Makefile.am 2009-08-05 07:39:45 UTC (rev 10720)
+++ trunk/drd/docs/Makefile.am 2009-08-05 08:08:18 UTC (rev 10721)
@@ -1 +0,0 @@
-EXTRA_DIST = drd-manual.xml
Modified: trunk/exp-bbv/Makefile.am
===================================================================
--- trunk/exp-bbv/Makefile.am 2009-08-05 07:39:45 UTC (rev 10720)
+++ trunk/exp-bbv/Makefile.am 2009-08-05 08:08:18 UTC (rev 10721)
@@ -1,5 +1,7 @@
include $(top_srcdir)/Makefile.tool.am
+EXTRA_DIST = docs/bbv-manual.xml
+
#----------------------------------------------------------------------------
# exp-bbv-<platform>
#----------------------------------------------------------------------------
Deleted: trunk/exp-bbv/docs/Makefile.am
===================================================================
--- trunk/exp-bbv/docs/Makefile.am 2009-08-05 07:39:45 UTC (rev 10720)
+++ trunk/exp-bbv/docs/Makefile.am 2009-08-05 08:08:18 UTC (rev 10721)
@@ -1,2 +0,0 @@
-EXTRA_DIST = bbv-manual.xml
-
Modified: trunk/exp-ptrcheck/Makefile.am
===================================================================
--- trunk/exp-ptrcheck/Makefile.am 2009-08-05 07:39:45 UTC (rev 10720)
+++ trunk/exp-ptrcheck/Makefile.am 2009-08-05 08:08:18 UTC (rev 10721)
@@ -1,5 +1,7 @@
include $(top_srcdir)/Makefile.tool.am
+EXTRA_DIST = docs/pc-manual.xml
+
#----------------------------------------------------------------------------
# Headers, etc
#----------------------------------------------------------------------------
Deleted: trunk/exp-ptrcheck/docs/Makefile.am
===================================================================
--- trunk/exp-ptrcheck/docs/Makefile.am 2009-08-05 07:39:45 UTC (rev 10720)
+++ trunk/exp-ptrcheck/docs/Makefile.am 2009-08-05 08:08:18 UTC (rev 10721)
@@ -1 +0,0 @@
-EXTRA_DIST = pc-manual.xml
Modified: trunk/helgrind/Makefile.am
===================================================================
--- trunk/helgrind/Makefile.am 2009-08-05 07:39:45 UTC (rev 10720)
+++ trunk/helgrind/Makefile.am 2009-08-05 08:08:18 UTC (rev 10721)
@@ -1,5 +1,10 @@
include $(top_srcdir)/Makefile.tool.am
+EXTRA_DIST = \
+ docs/hg-manual.xml \
+ README_MSMProp2.txt \
+ README_YARD.txt
+
#----------------------------------------------------------------------------
# Headers, etc
#----------------------------------------------------------------------------
@@ -13,8 +18,6 @@
hg_wordset.h \
libhb.h
-EXTRA_DIST = README_MSMProp2.txt README_YARD.txt
-
#----------------------------------------------------------------------------
# helgrind-<platform>
#----------------------------------------------------------------------------
Deleted: trunk/helgrind/docs/Makefile.am
===================================================================
--- trunk/helgrind/docs/Makefile.am 2009-08-05 07:39:45 UTC (rev 10720)
+++ trunk/helgrind/docs/Makefile.am 2009-08-05 08:08:18 UTC (rev 10721)
@@ -1 +0,0 @@
-EXTRA_DIST = hg-manual.xml
Modified: trunk/lackey/Makefile.am
===================================================================
--- trunk/lackey/Makefile.am 2009-08-05 07:39:45 UTC (rev 10720)
+++ trunk/lackey/Makefile.am 2009-08-05 08:08:18 UTC (rev 10721)
@@ -1,5 +1,7 @@
include $(top_srcdir)/Makefile.tool.am
+EXTRA_DIST = docs/lk-manual.xml
+
#----------------------------------------------------------------------------
# lackey-<platform>
#----------------------------------------------------------------------------
Deleted: trunk/lackey/docs/Makefile.am
===================================================================
--- trunk/lackey/docs/Makefile.am 2009-08-05 07:39:45 UTC (rev 10720)
+++ trunk/lackey/docs/Makefile.am 2009-08-05 08:08:18 UTC (rev 10721)
@@ -1 +0,0 @@
-EXTRA_DIST = lk-manual.xml
Modified: trunk/massif/Makefile.am
===================================================================
--- trunk/massif/Makefile.am 2009-08-05 07:39:45 UTC (rev 10720)
+++ trunk/massif/Makefile.am 2009-08-05 08:08:18 UTC (rev 10721)
@@ -2,6 +2,12 @@
SUBDIRS += perf
+EXTRA_DIST = docs/ms-manual.xml
+
+#----------------------------------------------------------------------------
+# Headers, etc
+#----------------------------------------------------------------------------
+
bin_SCRIPTS = ms_print
#----------------------------------------------------------------------------
Deleted: trunk/massif/docs/Makefile.am
===================================================================
--- trunk/massif/docs/Makefile.am 2009-08-05 07:39:45 UTC (rev 10720)
+++ trunk/massif/docs/Makefile.am 2009-08-05 08:08:18 UTC (rev 10721)
@@ -1 +0,0 @@
-EXTRA_DIST = ms-manual.xml
Modified: trunk/memcheck/Makefile.am
===================================================================
--- trunk/memcheck/Makefile.am 2009-08-05 07:39:45 UTC (rev 10720)
+++ trunk/memcheck/Makefile.am 2009-08-05 08:08:18 UTC (rev 10721)
@@ -2,6 +2,8 @@
SUBDIRS += perf
+EXTRA_DIST = docs/mc-manual.xml docs/mc-tech-docs.xml
+
#----------------------------------------------------------------------------
# Headers
#----------------------------------------------------------------------------
Deleted: trunk/memcheck/docs/Makefile.am
===================================================================
--- trunk/memcheck/docs/Makefile.am 2009-08-05 07:39:45 UTC (rev 10720)
+++ trunk/memcheck/docs/Makefile.am 2009-08-05 08:08:18 UTC (rev 10721)
@@ -1 +0,0 @@
-EXTRA_DIST = mc-manual.xml mc-tech-docs.xml
Modified: trunk/none/Makefile.am
===================================================================
--- trunk/none/Makefile.am 2009-08-05 07:39:45 UTC (rev 10720)
+++ trunk/none/Makefile.am 2009-08-05 08:08:18 UTC (rev 10721)
@@ -1,5 +1,7 @@
include $(top_srcdir)/Makefile.tool.am
+EXTRA_DIST = docs/nl-manual.xml
+
#----------------------------------------------------------------------------
# none-<platform>
#----------------------------------------------------------------------------
Deleted: trunk/none/docs/Makefile.am
===================================================================
--- trunk/none/docs/Makefile.am 2009-08-05 07:39:45 UTC (rev 10720)
+++ trunk/none/docs/Makefile.am 2009-08-05 08:08:18 UTC (rev 10721)
@@ -1 +0,0 @@
-EXTRA_DIST = nl-manual.xml
|
|
From: Bart V. A. <bar...@gm...> - 2009-08-05 07:58:48
|
Nightly build on georgia-tech-cellbuzz-native ( cellbuzz, ppc64, Fedora 7, native ) Started at 2009-08-05 02:16:00 EDT Ended at 2009-08-05 03:58:26 EDT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... done Regression test results follow == 437 tests, 44 stderr failures, 9 stdout failures, 0 post failures == memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cases-full (stderr) memcheck/tests/leak-cases-summary (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/varinfo1 (stderr) memcheck/tests/varinfo2 (stderr) memcheck/tests/varinfo3 (stderr) memcheck/tests/varinfo4 (stderr) memcheck/tests/varinfo5 (stderr) memcheck/tests/varinfo6 (stderr) memcheck/tests/wrap8 (stderr) none/tests/empty-exe (stderr) none/tests/linux/mremap (stderr) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-vmx (stdout) none/tests/ppc32/round (stdout) none/tests/ppc32/test_gx (stdout) none/tests/ppc64/jm-fp (stdout) none/tests/ppc64/jm-vmx (stdout) none/tests/ppc64/round (stdout) none/tests/shell (stdout) none/tests/shell (stderr) none/tests/shell_valid1 (stderr) none/tests/shell_valid2 (stderr) none/tests/shell_valid3 (stderr) none/tests/shell_zerolength (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) exp-ptrcheck/tests/bad_percentify (stderr) exp-ptrcheck/tests/base (stderr) exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/fp (stderr) exp-ptrcheck/tests/globalerr (stderr) exp-ptrcheck/tests/hackedbz2 (stderr) exp-ptrcheck/tests/hp_bounds (stderr) exp-ptrcheck/tests/hp_dangle (stderr) exp-ptrcheck/tests/hsg (stderr) exp-ptrcheck/tests/justify (stderr) exp-ptrcheck/tests/partial_bad (stderr) exp-ptrcheck/tests/partial_good (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) exp-ptrcheck/tests/realloc (stderr) exp-ptrcheck/tests/stackerr (stderr) exp-ptrcheck/tests/strcpy (stderr) exp-ptrcheck/tests/supp (stderr) exp-ptrcheck/tests/tricky (stderr) exp-ptrcheck/tests/unaligned (stderr) exp-ptrcheck/tests/zero (stderr) |
|
From: <sv...@va...> - 2009-08-05 07:39:57
|
Author: njn
Date: 2009-08-05 08:39:45 +0100 (Wed, 05 Aug 2009)
New Revision: 10720
Log:
Various docs build tweaks:
- Remove roadmap.txt, as we haven't used it for a while and Bugzilla does it
better.
- Inline docs/{internals,images,xml,lib}/Makefile.am into docs/Makefile.am,
because they're very simple. Fewer Makefile.am files is good.
- Remove the dead docs/images/massif*.png files and all references to them.
Removed:
trunk/docs/images/Makefile.am
trunk/docs/internals/Makefile.am
trunk/docs/internals/roadmap.txt
trunk/docs/lib/Makefile.am
trunk/docs/xml/Makefile.am
Modified:
trunk/configure.in
trunk/docs/Makefile.am
Modified: trunk/configure.in
===================================================================
--- trunk/configure.in 2009-08-05 07:20:15 UTC (rev 10719)
+++ trunk/configure.in 2009-08-05 07:39:45 UTC (rev 10720)
@@ -1842,10 +1842,6 @@
valgrind.pc
glibc-2.X.supp
docs/Makefile
- docs/lib/Makefile
- docs/images/Makefile
- docs/internals/Makefile
- docs/xml/Makefile
tests/Makefile
tests/vg_regtest
perf/Makefile
Modified: trunk/docs/Makefile.am
===================================================================
--- trunk/docs/Makefile.am 2009-08-05 07:20:15 UTC (rev 10719)
+++ trunk/docs/Makefile.am 2009-08-05 07:39:45 UTC (rev 10720)
@@ -13,12 +13,63 @@
## END OF HACK
##-------------------------------------------------------------
+EXTRA_DIST = \
+ README \
+ images/home.png \
+ images/next.png \
+ images/prev.png \
+ images/up.png \
+ internals/3_0_BUGSTATUS.txt \
+ internals/3_1_BUGSTATUS.txt \
+ internals/3_2_BUGSTATUS.txt \
+ internals/3_3_BUGSTATUS.txt \
+ internals/3_4_BUGSTATUS.txt \
+ internals/BIG_APP_NOTES.txt \
+ internals/Darwin-notes.txt \
+ internals/directory-structure.txt \
+ internals/howto_BUILD_KDE42.txt \
+ internals/howto_oprofile.txt \
+ internals/m_replacemalloc.txt \
+ internals/m_syswrap.txt \
+ internals/module-structure.txt \
+ internals/notes.txt \
+ internals/porting-HOWTO.txt \
+ internals/mpi2entries.txt \
+ internals/porting-to-ARM.txt \
+ internals/register-uses.txt \
+ internals/release-HOWTO.txt \
+ internals/segments-seginfos.txt \
+ internals/threads-syscalls-signals.txt \
+ internals/tm-mutexstates.dot \
+ internals/tm-threadstates.dot \
+ internals/tracking-fn-entry-exit.txt \
+ internals/why-no-libc.txt \
+ internals/xml-output.txt \
+ internals/xml-output-protocol4.txt \
+ lib/line-wrap.xsl \
+ lib/vg_basic.css \
+ lib/vg-fo.xsl \
+ lib/vg-faq2txt.xsl \
+ lib/vg-html-chunk.xsl \
+ lib/vg-html-website.xsl \
+ lib/vg-html-common.xsl \
+ xml/FAQ.xml \
+ xml/dist-docs.xml \
+ xml/index.xml \
+ xml/licenses.xml \
+ xml/manual.xml \
+ xml/manual-intro.xml \
+ xml/manual-core.xml \
+ xml/manual-core-adv.xml \
+ xml/manual-writing-tools.xml \
+ xml/design-impl.xml \
+ xml/quick-start-guide.xml \
+ xml/tech-docs.xml \
+ xml/valgrind-manpage.xml \
+ xml/vg-entities.xml \
+ xml/xml_help.txt
-SUBDIRS = xml lib images internals
-EXTRA_DIST = README
-
-
##-------------------------------------------------------------------
## Below here is more ordinary make stuff...
##-------------------------------------------------------------------
@@ -97,7 +148,6 @@
export XML_CATALOG_FILES=$(XML_CATALOG_FILES) && \
mkdir -p $(myprintdir) && \
mkdir -p $(myprintdir)/images && \
- cp $(myimgdir)/massif-graph-sm.png $(myprintdir)/images && \
$(XSLTPROC) $(XSLTPROC_FLAGS) -o $(myprintdir)/index.fo $(XSL_FO_STYLE) $(myxmldir)/index.xml && \
(cd $(myprintdir) && \
( pdfxmltex index.fo && \
@@ -204,7 +254,6 @@
@echo "Generating valgrind_manual.pdf ..."
mkdir -p $(vgdir)/print
mkdir -p $(vgdir)/print/images
- cp $(myimgdir)/massif-graph-sm.png $(vgdir)/print/images/
$(XSLTPROC) $(XSLTPROC_FLAGS) -o $(vgdir)/print/manual.fo $(XSL_FO_STYLE) $(myxmldir)/index.xml
(cd $(vgdir)/print/ && \
( pdfxmltex manual.fo && \
Deleted: trunk/docs/images/Makefile.am
===================================================================
--- trunk/docs/images/Makefile.am 2009-08-05 07:20:15 UTC (rev 10719)
+++ trunk/docs/images/Makefile.am 2009-08-05 07:39:45 UTC (rev 10720)
@@ -1,3 +0,0 @@
-EXTRA_DIST = \
- home.png next.png prev.png up.png \
- massif-graph-sm.png massif-graph.png
Deleted: trunk/docs/internals/Makefile.am
===================================================================
--- trunk/docs/internals/Makefile.am 2009-08-05 07:20:15 UTC (rev 10719)
+++ trunk/docs/internals/Makefile.am 2009-08-05 07:39:45 UTC (rev 10720)
@@ -1,20 +0,0 @@
-EXTRA_DIST = \
- 3_0_BUGSTATUS.txt 3_1_BUGSTATUS.txt \
- 3_2_BUGSTATUS.txt 3_3_BUGSTATUS.txt \
- 3_4_BUGSTATUS.txt \
- BIG_APP_NOTES.txt \
- Darwin-notes.txt \
- directory-structure.txt \
- howto_BUILD_KDE42.txt \
- howto_oprofile.txt \
- m_replacemalloc.txt \
- m_syswrap.txt module-structure.txt notes.txt porting-HOWTO.txt \
- mpi2entries.txt \
- porting-to-ARM.txt \
- register-uses.txt \
- release-HOWTO.txt roadmap.txt \
- segments-seginfos.txt threads-syscalls-signals.txt \
- tm-mutexstates.dot tm-threadstates.dot tracking-fn-entry-exit.txt \
- why-no-libc.txt \
- xml-output.txt \
- xml-output-protocol4.txt
Deleted: trunk/docs/internals/roadmap.txt
===================================================================
--- trunk/docs/internals/roadmap.txt 2009-08-05 07:20:15 UTC (rev 10719)
+++ trunk/docs/internals/roadmap.txt 2009-08-05 07:39:45 UTC (rev 10720)
@@ -1,143 +0,0 @@
-=============================================================================
-Valgrind Roadmap
-=============================================================================
-
-This file serves as a rough roadmap for Valgrind development. It shows a
-minimal set of features we hope to implement for each version. It's in
-reverse chronological order.
-
------------------------------------------------------------------------------
-3.3.0
------------------------------------------------------------------------------
-Scheduled for mid-to-late 2007?
-
-* Add ppc{32,64}/AIX5 support [Done by Julian]
-
-* Rework Massif [Done by Nick]
-
-* Rework Helgrind [Done by Julian]
-
-* Add experimental tools (Omega + DRD) [Julian]
-
------------------------------------------------------------------------------
-3.2.4
------------------------------------------------------------------------------
-Scheduled for mid-2007?
-
------------------------------------------------------------------------------
-3.2.3
------------------------------------------------------------------------------
-[Was released on Jan 29, 2007]
-
------------------------------------------------------------------------------
-3.2.2
------------------------------------------------------------------------------
-[Was released on Jan 22, 2007]
-
------------------------------------------------------------------------------
-3.2.1
------------------------------------------------------------------------------
-Scheduled for Dec 06?
-[Was released on 16 Sep, 2006]
-
------------------------------------------------------------------------------
-3.2.0
------------------------------------------------------------------------------
-Scheduled for end-Mar 06 (3.1.0 + 4 months) ?
-[Was released on Sep 16, 2006]
-
-In order of increasing speculativeness
---------------------------------------
-
-* Add ppc64-linux support. [Done by Julian]
-
-* Fold in the V bit compression stuff if it works well (early signs
- are promising) and get rid of Addrcheck.
- [Done by Nick. Average speedup of 1.20x, shadow memory size reduction of
- 4.2x.]
-
-* Get function wrapping working again. [Done by Julian]
- Reinstate basic thread checks.
- Reinstate Helgrind.
-
-* Performance tuning:
- - faster register allocation in vex
- - improve stack-update pass [Done by Nick]
- - assess effect of branch misprediction in dispatchers
-
-* Try to accelerate development for Darwin ?
-
-Smaller things
---------------
-* Consider using the following defaults:
- --leak-check=yes
- --num-callers=20
-
-* Expose some of m_redir's functionality to tools so that Memcheck
- can replace strlen/strcmp on PPC32 (remove the 3.1.0 hack for this
- which checked in m_redir.c if the current tool was Memcheck).
- [Won't bother. The fix is worse than the problem it's trying to solve;
- the issue is that the replacement functions are in m_trampoline.S and must
- be between VG_(trampoline_stuff_start) and VG_(trampoline_stuff_end) for
- arcane reasons and moving them into a tool-visible place is a pain.]
-
------------------------------------------------------------------------------
-3.1.1
------------------------------------------------------------------------------
-Tentatively end-Dec 05 (3.1.0 + 1 month): fix any critical bugs in
-3.1.0.
-[Was released on Mar 16, 2006]
-
------------------------------------------------------------------------------
-3.1.0
------------------------------------------------------------------------------
-Scheduled for around November 2005. (Released 27 Nov 05).
-
-Definite
---------
-* Get 32-bit and 64-bit programs working smoothly on AMD64 (Tom?). Several
- levels of smoothness here, we should aim for at least level 3.
-
- 1. Be able to build a 32-bit valgrind on a 64-bit machine, so you can
- build and install both, and manually choose between bin/valgrind and
- bin64/valgrind.
- 2. Build both automatically when installing.
- 3. Choose the appropriate executable automatically at startup just from
- "valgrind".
- 4. With --trace-children=yes, allow 32-bit programs to exec 64-bit
- programs and vice versa, and invoke the appropriate Valgrind
- automatically.
- [All four levels done by Tom]
-
-* Get PPC32 working usably with Memcheck (Julian). Has already improved a
- lot since. Get Cachegrind working with it (Nick).
- [Both done by Julian]
-
-* Rewrite address space manager; statically link the core with
- each tool; remove all glibc dependencies (Julian).
- [Done by Julian]
-
-* What about --time-stamp=yes?
- [Fixed by Julian to give relative time since startup]
-
-* Make it work with GCC 2.95 (bug #111781) -- don't put declarations after
- statements in blocks. Do it after merging ASPACEM with the trunk.
- -Wdeclaration-after-statement is the GCC warning that detects this, but
- it is only present in GCC after 3.4.0 (ie. not in 3.0.X--3.3.X)...
- [Done by Tom and others]
-
-* We need to reintroduce some kind of core/tool interface versioning,
- so that if external tools link with libcoregrind.a incompatibilities
- are detected.
-
-Maybe
------
-* Get pthread modelling and Helgrind working again. Requires function
- wrapping (Nick).
- [Won't happen for 3.1.0. Function wrapping is difficult.]
-
-* Reinstate Addrcheck and/or implement V-bit compression in Memcheck (?).
- [Won't happen for 3.1.0.]
-
-* Allow suppressions by filename + line number? (Joseph Link's patch)
-
Deleted: trunk/docs/lib/Makefile.am
===================================================================
--- trunk/docs/lib/Makefile.am 2009-08-05 07:20:15 UTC (rev 10719)
+++ trunk/docs/lib/Makefile.am 2009-08-05 07:39:45 UTC (rev 10720)
@@ -1,8 +0,0 @@
-EXTRA_DIST = \
- vg_basic.css \
- vg-fo.xsl \
- vg-faq2txt.xsl \
- line-wrap.xsl \
- vg-html-chunk.xsl \
- vg-html-website.xsl \
- vg-html-common.xsl
Deleted: trunk/docs/xml/Makefile.am
===================================================================
--- trunk/docs/xml/Makefile.am 2009-08-05 07:20:15 UTC (rev 10719)
+++ trunk/docs/xml/Makefile.am 2009-08-05 07:39:45 UTC (rev 10720)
@@ -1,16 +0,0 @@
-EXTRA_DIST = \
- FAQ.xml \
- dist-docs.xml \
- index.xml \
- licenses.xml \
- manual.xml \
- manual-intro.xml \
- manual-core.xml \
- manual-core-adv.xml \
- manual-writing-tools.xml\
- design-impl.xml \
- quick-start-guide.xml \
- tech-docs.xml \
- valgrind-manpage.xml \
- vg-entities.xml \
- xml_help.txt
|
|
From: <sv...@va...> - 2009-08-05 07:20:27
|
Author: njn Date: 2009-08-05 08:20:15 +0100 (Wed, 05 Aug 2009) New Revision: 10719 Log: Use actual URL links in the BBV docs. Modified: trunk/exp-bbv/docs/bbv-manual.xml Modified: trunk/exp-bbv/docs/bbv-manual.xml =================================================================== --- trunk/exp-bbv/docs/bbv-manual.xml 2009-08-05 07:15:28 UTC (rev 10718) +++ trunk/exp-bbv/docs/bbv-manual.xml 2009-08-05 07:20:15 UTC (rev 10719) @@ -20,9 +20,9 @@ </para> <para> - BBV is tool that generates basic block vectors - for use with the SimPoint analysis tool - (http://www.cse.ucsd.edu/~calder/simpoint/). + BBV is tool that generates basic block vectors for use with the + <ulink url="http://www.cse.ucsd.edu/~calder/simpoint/">SimPoint</ulink> + analysis tool. The SimPoint methodology enables speeding up architectural simulations by only running a small portion of a program and then extrapolating total behavior from this @@ -69,9 +69,9 @@ </para> <para> - To create actual SimPoint results, you will need the - SimPoint utility, available from the SimPoint webpage - (http://www.cse.ucsd.edu/~calder/simpoint/). + To create actual SimPoint results, you will need the SimPoint utility, + available from the + <ulink url="http://www.cse.ucsd.edu/~calder/simpoint/">SimPoint webpage</ulink>. Assuming you have downloaded SimPoint 3.2 and compiled it, create SimPoint results with a command like the following: |
|
From: <sv...@va...> - 2009-08-05 07:15:46
|
Author: njn
Date: 2009-08-05 08:15:28 +0100 (Wed, 05 Aug 2009)
New Revision: 10718
Log:
Tweaks to Ptrcheck's manual chapter.
Modified:
trunk/exp-ptrcheck/docs/pc-manual.xml
Modified: trunk/exp-ptrcheck/docs/pc-manual.xml
===================================================================
--- trunk/exp-ptrcheck/docs/pc-manual.xml 2009-08-05 06:57:45 UTC (rev 10717)
+++ trunk/exp-ptrcheck/docs/pc-manual.xml 2009-08-05 07:15:28 UTC (rev 10718)
@@ -49,7 +49,7 @@
<sect1 id="pc-manual.options" xreflabel="Ptrcheck Options">
<title>Ptrcheck Options</title>
-<para>The following end-user options are available:</para>
+<para>Ptrcheck-specific options are:</para>
<!-- start of xi:include in the manpage -->
<variablelist id="pc.opts.list">
@@ -97,26 +97,6 @@
</variablelist>
<!-- end of xi:include in the manpage -->
-<!-- start of xi:include in the manpage -->
-<para>In addition, the following debugging options are available for
-Ptrcheck:</para>
-
-<variablelist id="hg.debugopts.list">
-
- <varlistentry id="opt.trace-malloc" xreflabel="--trace-malloc">
- <term>
- <option><![CDATA[--trace-malloc=no|yes [no]
- ]]></option>
- </term>
- <listitem>
- <para>Show all client malloc (etc) and free (etc) requests.</para>
- </listitem>
- </varlistentry>
-
-</variablelist>
-<!-- end of xi:include in the manpage -->
-
-
</sect1>
@@ -138,19 +118,19 @@
out of bounds, or if the block has been freed.</para>
<para>Of course it is rarely the case that one wants to access a block
-only at the exact address returned by malloc (et al). Ptrcheck
-understands that adding or subtracting offsets from a pointer to a
+only at the exact address returned by <function>malloc</function> et al.
+Ptrcheck understands that adding or subtracting offsets from a pointer to a
block results in a pointer to the same block.</para>
<para>At a fundamental level, this scheme works because a correct
program cannot make assumptions about the addresses returned by
-malloc. In particular it cannot make any assumptions about the
-differences in addresses returned by subsequent calls to malloc.
-Hence there are very few ways to take an address returned by malloc,
-modify it, and still have a valid address. In short, the only
-allowable operations are adding and subtracting other non-pointer
-values. Almost all other operations produce a value which cannot
-possibly be a valid pointer.</para>
+<function>malloc</function> et al. In particular it cannot make any
+assumptions about the differences in addresses returned by subsequent calls
+to <function>malloc</function> et al. Hence there are very few ways to take
+an address returned by <function>malloc</function>, modify it, and still
+have a valid address. In short, the only allowable operations are adding
+and subtracting other non-pointer values. Almost all other operations
+produce a value which cannot possibly be a valid pointer.</para>
</sect1>
@@ -171,12 +151,10 @@
the DWARF3 debugging format does not provide a way to represent such
information, so we have to resort to a heuristic technique to
approximate the same information. The key observation is that
-</para>
-
- <para>
+ <emphasis>
if a memory referencing instruction accesses inside a stack or
global array once, then it is highly likely to always access that
- same array</para>
+ same array</emphasis>.</para>
<para>To see how this might be useful, consider the following buggy
fragment:</para>
@@ -199,19 +177,20 @@
<para>There is an important caveat.</para>
-<para>Imagine a function such as memcpy, which is used to read and
-write many different areas of memory over the lifetime of the program.
-If we insist that the read and write instructions in its memory
-copying loop only ever access one particular stack or global variable,
-we will be flooded with errors resulting from calls to memcpy.</para>
+<para>Imagine a function such as <function>memcpy</function>, which is used
+to read and write many different areas of memory over the lifetime of the
+program. If we insist that the read and write instructions in its memory
+copying loop only ever access one particular stack or global variable, we
+will be flooded with errors resulting from calls to
+<function>memcpy</function>.</para>
<para>To avoid this problem, Ptrcheck instantiates fresh likely-target
records for each entry to a function, and discards them on exit. This
-allows detection of cases where (eg) memcpy overflows its source or
-destination buffers for any specific call, but does not carry any
-restriction from one call to the next. Indeed, multiple threads may
-be multiple simultaneous calls to (eg) memcpy without mutual
-interference.</para>
+allows detection of cases where (e.g.) <function>memcpy</function> overflows
+its source or destination buffers for any specific call, but does not carry
+any restriction from one call to the next. Indeed, multiple threads may be
+multiple simultaneous calls to (e.g.) <function>memcpy</function> without
+mutual interference.</para>
</sect1>
@@ -244,8 +223,8 @@
<para>Ptrcheck's approach is to keep track of pointers derived from
heap blocks. It tracks pointers which are derived directly from calls
-to malloc et al, but also ones derived indirectly, by adding or
-subtracting offsets from the directly-derived pointers. When a
+to <function>malloc</function> et al, but also ones derived indirectly, by
+adding or subtracting offsets from the directly-derived pointers. When a
pointer is finally used to access memory, Ptrcheck compares the access
address with that of the block it was originally derived from, and
reports an error if the access address is not within the block
@@ -275,18 +254,17 @@
detection with Memcheck is close to impossible and would likely
involve several gigabytes of extra storage.</para>
-<para>In defense of Memcheck ...</para>
+<para>Having said all that, remember that Memcheck performs uninitialised
+value checking, invalid and mismatched free checking, overlap checking, and
+leak checking, none of which Ptrcheck do. Memcheck has also benefitted from
+years of refinement, tuning, and experience with production-level usage, and
+so is much faster than Ptrcheck as it currently stands.
+</para>
-<para>Remember that Memcheck performs uninitialised value checking,
-which Ptrcheck does not. Memcheck has also benefitted from years of
-refinement, tuning, and experience with production-level usage, and so
-is much faster than Ptrcheck as it currently stands, as of October
-2008.</para>
+<para>Consequently we recommend you first make your programs run Memcheck
+clean. Once that's done, try Ptrcheck to see if you can shake out any
+further heap, global or stack errors.</para>
-<para>Consequently it is recommended to first make your programs run
-Memcheck clean. Once that's done, try Ptrcheck to see if you can
-shake out any further heap, global or stack errors.</para>
-
</sect1>
@@ -323,20 +301,21 @@
<listitem>
<para>Heap checks: Ptrcheck needs to "understand" which system
calls return pointers and which don't. Many, but not all system
- calls are handled. If an unhandled one is encountered, Ptrcheck
- will abort.</para>
+ calls are handled. If an unhandled one is encountered, Ptrcheck will
+ abort. Fortunately, adding support for a new syscall is very
+ easy.</para>
</listitem>
<listitem>
- <para>Stack checks: It follows from the description above (How Ptrcheck
- Works: Stack and Global Checks) that the first access by a memory
- referencing instruction to a stack or global array creates an
- association between that instruction and the array, which is
- checked on subsequent accesses by that instruction, until the
- containing function exits. Hence, the first access by an
- instruction to an array (in any given function instantiation) is
- not checked for overrun, since Ptrcheck uses that as the "example"
- of how subsequent accesses should behave.</para>
+ <para>Stack checks: It follows from the description above (<xref
+ linkend="pc-manual.how-works.sg-checks"/>) that the first access by a
+ memory referencing instruction to a stack or global array creates an
+ association between that instruction and the array, which is checked on
+ subsequent accesses by that instruction, until the containing function
+ exits. Hence, the first access by an instruction to an array (in any
+ given function instantiation) is not checked for overrun, since Ptrcheck
+ uses that as the "example" of how subsequent accesses should
+ behave.</para>
</listitem>
<listitem>
@@ -393,9 +372,9 @@
<listitem>
<para>Coverage: the heap checking is relatively robust, requiring
- only that Ptrcheck can see calls to malloc/free et al. In that
- sense it has debug-info requirements comparable with Memcheck, and
- is able to heap-check programs even with no debugging information
+ only that Ptrcheck can see calls to <function>malloc</function> et al.
+ In that sense it has debug-info requirements comparable with Memcheck,
+ and is able to heap-check programs even with no debugging information
attached.</para>
<para>Stack/global checking is much more fragile. If a shared
@@ -424,7 +403,7 @@
PowerPC platforms, only on x86 and amd64 targets. That's because
the stack and global checking requires tracking function calls and
exits reliably, and there's no obvious way to do it with the PPC
- ABIs. (cf with the x86 and amd64 ABIs this is relatively
+ ABIs. (In comparison, with the x86 and amd64 ABIs this is relatively
straightforward.)</para>
</listitem>
@@ -444,8 +423,8 @@
<sect1 id="pc-manual.todo-user-visible"
- xreflabel="Still To Do: User Visible Functionality">
-<title>Still To Do: User Visible Functionality</title>
+ xreflabel="Still To Do: User-visible Functionality">
+<title>Still To Do: User-visible Functionality</title>
<itemizedlist>
@@ -494,7 +473,7 @@
</listitem>
<listitem>
- <para>h_main.c: move vast amounts of arch-dependent uglyness
+ <para>h_main.c: move vast amounts of arch-dependent ugliness
(get_IntRegInfo et al) to its own source file, a la
mc_machine.c.</para>
</listitem>
@@ -519,7 +498,7 @@
<listitem>
<para>sg_main.c: fix compute_II_hash to make it a bit more sensible
for ppc32/64 targets (except that sg_ doesn't work on ppc32/64
- targets, so this is a bit academic at the mo).</para>
+ targets, so this is a bit academic at the moment).</para>
</listitem>
</itemizedlist>
|
|
From: <sv...@va...> - 2009-08-05 06:58:00
|
Author: njn
Date: 2009-08-05 07:57:45 +0100 (Wed, 05 Aug 2009)
New Revision: 10717
Log:
- Rejigged Lackey's manual
- Made it count calls to main() by default, since _dl_runtime_resolve() no
longer appears to exist.
- A couple of other minor Lackey things.
Modified:
trunk/lackey/docs/lk-manual.xml
trunk/lackey/lk_main.c
Modified: trunk/lackey/docs/lk-manual.xml
===================================================================
--- trunk/lackey/docs/lk-manual.xml 2009-08-05 06:34:27 UTC (rev 10716)
+++ trunk/lackey/docs/lk-manual.xml 2009-08-05 06:57:45 UTC (rev 10717)
@@ -14,109 +14,12 @@
<sect1 id="lk-manual.overview" xreflabel="Overview">
<title>Overview</title>
-<para>Lackey is a simple valgrind tool that does some basic program
-measurement. It adds quite a lot of simple instrumentation to the
-program's code. It is primarily intended to be of use as an example
-tool, and consequently emphasises clarity of implementation
-over performance.</para>
+<para>Lackey is a simple Valgrind tool that does various kinds of basic
+program measurement. It adds quite a lot of simple instrumentation to the
+program's code. It is primarily intended to be of use as an example tool,
+and consequently emphasises clarity of implementation over
+performance.</para>
-<para>It measures and reports various things.</para>
-
-<orderedlist>
-
- <listitem>
- <para>When command line option
- <option>--basic-counts=yes</option> is specified,
- it prints the following statistics and information about the execution of
- the client program:</para>
-
- <orderedlist>
-
- <listitem>
- <para>The number of calls to
- <computeroutput>_dl_runtime_resolve()</computeroutput>, the
- function in glibc's dynamic linker that resolves function
- references to shared objects.</para>
- <para>You can change the name of the function tracked with command line
- option <option>--fnname=<name></option>.</para>
- </listitem>
-
- <listitem>
- <para>The number of conditional branches encountered and the
- number and proportion of those taken.</para>
- </listitem>
-
- <listitem>
- <para>The number of superblocks entered and completed by the
- program. Note that due to optimisations done by the JIT, this
- is not at all an accurate value.</para>
- </listitem>
-
- <listitem>
- <para>The number of guest (x86, amd64, ppc, etc.) instructions and IR
- statements executed. IR is Valgrind's RISC-like intermediate
- representation via which all instrumentation is done.
- </para>
- </listitem>
-
- <listitem>
- <para>Ratios between some of these counts.</para>
- </listitem>
-
- <listitem>
- <para>The exit code of the client program.</para>
- </listitem>
-
- </orderedlist>
- </listitem>
-
- <listitem>
- <para>When command line option
- <option>--detailed-counts=yes</option> is
- specified, a table is printed with counts of loads, stores and ALU
- operations for various types of operands.</para>
-
- <para>The types are identified by their IR name ("I1" ... "I128",
- "F32", "F64", and "V128").</para>
- </listitem>
-
- <listitem>
- <para>When command line option
- <option>--trace-mem=yes</option> is
- specified, it prints out the size and address of almost every load and
- store made by the program. See the comments at the top of the file
- <computeroutput>lackey/lk_main.c</computeroutput> for details about
- the output format, how it works, and inaccuracies in the address trace.
- </para>
- </listitem>
-
- <listitem>
- <para>When command line option
- <option>--trace-superblocks=yes</option> is
- specified, it prints out the address of every superblock
- (extended basic block) executed by the program. This is
- primarily of interest to Valgrind developers. See the comments at
- the top of the file <computeroutput>lackey/lk_main.c</computeroutput>
- for details about the output format.
- </para>
- </listitem>
-
-</orderedlist>
-
-<para>Note that Lackey runs quite slowly, especially when
-<option>--detailed-counts=yes</option> is specified.
-It could be made to run a lot faster by doing a slightly more
-sophisticated job of the instrumentation, but that would undermine
-its role as a simple example tool. Hence we have chosen not to do
-so.</para>
-
-<para>Note also that <option>--trace-mem=yes</option>
-and <option>--trace-superblocks=yes</option> create
-immense amounts of output. If you are saving the output in a file,
-you can eat up tens of gigabytes of disk space very quickly.
-As a result of printing out so much stuff, they also cause the program
-to run absolutely utterly unbelievably slowly.</para>
-
</sect1>
@@ -133,7 +36,47 @@
<option><![CDATA[--basic-counts=<no|yes> [default: yes] ]]></option>
</term>
<listitem>
- <para>Count basic events, as described above.</para>
+ <para>When enabled, Lackey prints the following statistics and
+ information about the execution of the client program:</para>
+
+ <orderedlist>
+
+ <listitem>
+ <para>The number of calls to the function specified by the
+ <option>--fnname</option> option (the default is
+ <computeroutput>main</computeroutput>).
+ If the program has had its symbols stripped, the count will always
+ be zero.</para>
+ </listitem>
+
+ <listitem>
+ <para>The number of conditional branches encountered and the
+ number and proportion of those taken.</para>
+ </listitem>
+
+ <listitem>
+ <para>The number of superblocks entered and completed by the
+ program. Note that due to optimisations done by the JIT, this
+ is not at all an accurate value.</para>
+ </listitem>
+
+ <listitem>
+ <para>The number of guest (x86, amd64, ppc, etc.) instructions and IR
+ statements executed. IR is Valgrind's RISC-like intermediate
+ representation via which all instrumentation is done.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>Ratios between some of these counts.</para>
+ </listitem>
+
+ <listitem>
+ <para>The exit code of the client program.</para>
+ </listitem>
+
+ </orderedlist>
+
</listitem>
</varlistentry>
@@ -142,38 +85,49 @@
<option><![CDATA[--detailed-counts=<no|yes> [default: no] ]]></option>
</term>
<listitem>
- <para>Count loads, stores and alu ops, differentiated by their
- IR types.</para>
+ <para>When enabled, Lackey prints a table containing counts of loads,
+ stores and ALU operations, differentiated by their IR types.
+ The IR types are identified by their IR name ("I1", "I8", ... "I128",
+ "F32", "F64", and "V128").</para>
</listitem>
</varlistentry>
- <varlistentry id="opt.fnname" xreflabel="--fnname">
+ <varlistentry id="opt.trace-mem" xreflabel="--trace-mem">
<term>
- <option><![CDATA[--fnname=<name> [default: _dl_runtime_resolve()] ]]></option>
+ <option><![CDATA[--trace-mem=<no|yes> [default: no] ]]></option>
</term>
<listitem>
- <para>Count calls to the function <name>.</para>
+ <para>When enabled, Lackey prints the size and address of almost every
+ memory access made by the program. See the comments at the top of
+ the file <computeroutput>lackey/lk_main.c</computeroutput> for details
+ about the output format, how it works, and inaccuracies in the address
+ trace. Note that this option produces immense amounts of output.</para>
</listitem>
</varlistentry>
- <varlistentry id="opt.trace-mem" xreflabel="--trace-mem">
+ <varlistentry id="opt.trace-superblocks" xreflabel="--trace-superblocks">
<term>
- <option><![CDATA[--trace-mem=<no|yes> [default: no] ]]></option>
+ <option><![CDATA[--trace-superblocks=<no|yes> [default: no] ]]></option>
</term>
<listitem>
- <para>Produce a log of all memory references, as described
- above.</para>
+ <para>When enabled,
+ Lackey prints out the address of every superblock
+ (a single entry, multiple exit, linear chunk of code) executed by the
+ program. This is primarily of interest to Valgrind developers. See
+ the comments at the top of the file
+ <computeroutput>lackey/lk_main.c</computeroutput> for details about
+ the output format. Note that this option produces large amounts of
+ output.</para>
</listitem>
</varlistentry>
- <varlistentry id="opt.trace-superblocks" xreflabel="--trace-superblocks">
+ <varlistentry id="opt.fnname" xreflabel="--fnname">
<term>
- <option><![CDATA[--trace-superblocks=<no|yes> [default: no] ]]></option>
+ <option><![CDATA[--fnname=<name> [default: main] ]]></option>
</term>
<listitem>
- <para>Print a line of text giving the address of each superblock
- (single entry, multiple exit chunk of code) executed
- by the program.</para>
+ <para>Changes the function for which calls are counted when
+ <option>--basic-counts=yes</option> is specified.</para>
</listitem>
</varlistentry>
Modified: trunk/lackey/lk_main.c
===================================================================
--- trunk/lackey/lk_main.c 2009-08-05 06:34:27 UTC (rev 10716)
+++ trunk/lackey/lk_main.c 2009-08-05 06:57:45 UTC (rev 10717)
@@ -132,7 +132,7 @@
// want to analyse locality of memory accesses -- but is not good if
// absolute addresses are important.
//
-// Despite all these warnings, Dullard's results should be good enough for a
+// Despite all these warnings, Lackey's results should be good enough for a
// wide range of purposes. For example, Cachegrind shares all the above
// shortcomings and it is still useful.
//
@@ -192,7 +192,7 @@
/* The name of the function of which the number of calls (under
* --basic-counts=yes) is to be counted, with default. Override with command
* line option --fnname. */
-static Char* clo_fnname = "_dl_runtime_resolve";
+static Char* clo_fnname = "main";
static Bool lk_process_cmd_line_option(Char* arg)
{
@@ -212,12 +212,12 @@
static void lk_print_usage(void)
{
VG_(printf)(
-" --basic-counts=no|yes count instructions, jumps, etc. [no]\n"
+" --basic-counts=no|yes count instructions, jumps, etc. [yes]\n"
" --detailed-counts=no|yes count loads, stores and alu ops [no]\n"
" --trace-mem=no|yes trace all loads and stores [no]\n"
" --trace-superblocks=no|yes trace all superblock entries [no]\n"
" --fnname=<name> count calls to <name> (only used if\n"
-" --basic-count=yes) [_dl_runtime_resolve]\n"
+" --basic-count=yes) [main]\n"
);
}
@@ -883,7 +883,8 @@
ULong total_Jccs = n_Jccs + n_IJccs;
ULong taken_Jccs = (n_Jccs - n_Jccs_untaken) + n_IJccs_untaken;
- VG_(umsg)("Counted %'llu calls to %s()\n", n_func_calls, clo_fnname);
+ VG_(umsg)("Counted %'llu call%s to %s()\n",
+ n_func_calls, ( n_func_calls==1 ? "" : "s" ), clo_fnname);
VG_(umsg)("\n");
VG_(umsg)("Jccs:\n");
|
|
From: <sv...@va...> - 2009-08-05 06:34:40
|
Author: njn
Date: 2009-08-05 07:34:27 +0100 (Wed, 05 Aug 2009)
New Revision: 10716
Log:
Various fix-ups for Memcheck's manual chapter.
Modified:
trunk/memcheck/docs/mc-manual.xml
Modified: trunk/memcheck/docs/mc-manual.xml
===================================================================
--- trunk/memcheck/docs/mc-manual.xml 2009-08-05 05:11:02 UTC (rev 10715)
+++ trunk/memcheck/docs/mc-manual.xml 2009-08-05 06:34:27 UTC (rev 10716)
@@ -40,7 +40,7 @@
<listitem>
<para>Overlapping <computeroutput>src</computeroutput> and
<computeroutput>dst</computeroutput> pointers in
- <computeroutput>memcpy()</computeroutput> and related
+ <computeroutput>memcpy</computeroutput> and related
functions.</para>
</listitem>
@@ -94,7 +94,9 @@
the block was freed. Likewise, if it should turn out to be just off
the end of a heap block, a common result of off-by-one-errors in
array subscripting, you'll be informed of this fact, and also where the
-block was allocated.</para>
+block was allocated. If you use the <option><xref
+linkend="opt.read-var-info"/></option> option Memcheck will run more slowly
+but may give a more detailed description of any illegal address.</para>
<para>In this example, Memcheck can't identify the address. Actually
the address is on the stack, but, for some reason, this is not a valid
@@ -129,8 +131,8 @@
<para>An uninitialised-value use error is reported when your program
uses a value which hasn't been initialised -- in other words, is
undefined. Here, the undefined value is used somewhere inside the
-printf() machinery of the C library. This error was reported when
-running the following small program:</para>
+<function>printf</function> machinery of the C library. This error was
+reported when running the following small program:</para>
<programlisting><![CDATA[
int main()
{
@@ -142,13 +144,13 @@
junk (uninitialised) data as much as it likes. Memcheck observes this
and keeps track of the data, but does not complain. A complaint is
issued only when your program attempts to make use of uninitialised
-data. In this example, x is uninitialised. Memcheck observes the value
-being passed to <literal>_IO_printf</literal> and thence to
-<literal>_IO_vfprintf</literal>, but makes no comment. However,
-<literal>_IO_vfprintf</literal> has to examine the value of
-x so it can turn it into the
-corresponding ASCII string, and it is at this point that Memcheck
-complains.</para>
+data in a way that might affect your program's externally-visible behaviour.
+In this example, <varname>x</varname> is uninitialised. Memcheck observes
+the value being passed to <function>_IO_printf</function> and thence to
+<function>_IO_vfprintf</function>, but makes no comment. However,
+<function>_IO_vfprintf</function> has to examine the value of
+<varname>x</varname> so it can turn it into the corresponding ASCII string,
+and it is at this point that Memcheck complains.</para>
<para>Sources of uninitialised data tend to be:</para>
<itemizedlist>
@@ -173,6 +175,74 @@
+<sect2 id="mc-manual.bad-syscall-args"
+ xreflabel="Use of uninitialised or unaddressable values in system
+ calls">
+<title>Use of uninitialised or unaddressable values in system
+ calls</title>
+
+<para>Memcheck checks all parameters to system calls:
+<itemizedlist>
+ <listitem>
+ <para>It checks all the direct parameters themselves, whether they are
+ initialised.</para>
+ </listitem>
+ <listitem>
+ <para>Also, if a system call needs to read from a buffer provided by
+ your program, Memcheck checks that the entire buffer is addressable
+ and its contents are initialised.</para>
+ </listitem>
+ <listitem>
+ <para>Also, if the system call needs to write to a user-supplied
+ buffer, Memcheck checks that the buffer is addressable.</para>
+ </listitem>
+</itemizedlist>
+</para>
+
+<para>After the system call, Memcheck updates its tracked information to
+precisely reflect any changes in memory state caused by the system
+call.</para>
+
+<para>Here's an example of two system calls with invalid parameters:</para>
+<programlisting><![CDATA[
+ #include <stdlib.h>
+ #include <unistd.h>
+ int main( void )
+ {
+ char* arr = malloc(10);
+ int* arr2 = malloc(sizeof(int));
+ write( 1 /* stdout */, arr, 10 );
+ exit(arr2[0]);
+ }
+]]></programlisting>
+
+<para>You get these complaints ...</para>
+<programlisting><![CDATA[
+ Syscall param write(buf) points to uninitialised byte(s)
+ at 0x25A48723: __write_nocancel (in /lib/tls/libc-2.3.3.so)
+ by 0x259AFAD3: __libc_start_main (in /lib/tls/libc-2.3.3.so)
+ by 0x8048348: (within /auto/homes/njn25/grind/head4/a.out)
+ Address 0x25AB8028 is 0 bytes inside a block of size 10 alloc'd
+ at 0x259852B0: malloc (vg_replace_malloc.c:130)
+ by 0x80483F1: main (a.c:5)
+
+ Syscall param exit(error_code) contains uninitialised byte(s)
+ at 0x25A21B44: __GI__exit (in /lib/tls/libc-2.3.3.so)
+ by 0x8048426: main (a.c:8)
+]]></programlisting>
+
+<para>... because the program has (a) written uninitialised junk
+from the heap block to the standard output, and (b) passed an
+uninitialised value to <function>exit</function>. Note that the first
+error refers to the memory pointed to by
+<computeroutput>buf</computeroutput> (not
+<computeroutput>buf</computeroutput> itself), but the second error
+refers directly to <computeroutput>exit</computeroutput>'s argument
+<computeroutput>arr2[0]</computeroutput>.</para>
+
+</sect2>
+
+
<sect2 id="mc-manual.badfrees" xreflabel="Illegal frees">
<title>Illegal frees</title>
@@ -194,15 +264,17 @@
twice. As with the illegal read/write errors, Memcheck attempts to
make sense of the address freed. If, as here, the address is one
which has previously been freed, you wil be told that -- making
-duplicate frees of the same block easy to spot.</para>
+duplicate frees of the same block easy to spot. You will also get this
+message if you try to free a pointer that doesn't point to the start of a
+heap block.</para>
</sect2>
<sect2 id="mc-manual.rudefn"
- xreflabel="When a block is freed with an inappropriate deallocation
+ xreflabel="When a heap block is freed with an inappropriate deallocation
function">
-<title>When a block is freed with an inappropriate deallocation
+<title>When a heap block is freed with an inappropriate deallocation
function</title>
<para>In the following example, a block allocated with
@@ -234,13 +306,13 @@
deallocate with <function>free</function>.</para>
</listitem>
<listitem>
- <para>If allocated with <function>new[]</function>, you must
- deallocate with <function>delete[]</function>.</para>
- </listitem>
- <listitem>
<para>If allocated with <function>new</function>, you must deallocate
with <function>delete</function>.</para>
</listitem>
+ <listitem>
+ <para>If allocated with <function>new[]</function>, you must
+ deallocate with <function>delete[]</function>.</para>
+ </listitem>
</itemizedlist>
<para>The worst thing is that on Linux apparently it doesn't matter if
@@ -254,94 +326,30 @@
objects allocated by <function>new[]</function> because the compiler
stores the size of the array and the pointer-to-member to the
destructor of the array's content just before the pointer actually
-returned. This implies a variable-sized overhead in what's returned
-by <function>new</function> or <function>new[]</function>.</para>
+returned. <function>delete</function> doesn't account for this and will get
+confused, possibly corrupting the heap.</para>
</sect2>
-<sect2 id="mc-manual.badperm"
- xreflabel="Passing system call parameters with
- inadequate read/write permissions">
-<title>Passing system call parameters with inadequate read/write
-permissions</title>
-
-<para>Memcheck checks all parameters to system calls:
-<itemizedlist>
- <listitem>
- <para>It checks all the direct parameters themselves.</para>
- </listitem>
- <listitem>
- <para>Also, if a system call needs to read from a buffer provided by
- your program, Memcheck checks that the entire buffer is addressable
- and has valid data, ie, it is readable.</para>
- </listitem>
- <listitem>
- <para>Also, if the system call needs to write to a user-supplied
- buffer, Memcheck checks that the buffer is addressable.</para>
- </listitem>
-</itemizedlist>
-</para>
-
-<para>After the system call, Memcheck updates its tracked information to
-precisely reflect any changes in memory permissions caused by the system
-call.</para>
-
-<para>Here's an example of two system calls with invalid parameters:</para>
-<programlisting><![CDATA[
- #include <stdlib.h>
- #include <unistd.h>
- int main( void )
- {
- char* arr = malloc(10);
- int* arr2 = malloc(sizeof(int));
- write( 1 /* stdout */, arr, 10 );
- exit(arr2[0]);
- }
-]]></programlisting>
-
-<para>You get these complaints ...</para>
-<programlisting><![CDATA[
- Syscall param write(buf) points to uninitialised byte(s)
- at 0x25A48723: __write_nocancel (in /lib/tls/libc-2.3.3.so)
- by 0x259AFAD3: __libc_start_main (in /lib/tls/libc-2.3.3.so)
- by 0x8048348: (within /auto/homes/njn25/grind/head4/a.out)
- Address 0x25AB8028 is 0 bytes inside a block of size 10 alloc'd
- at 0x259852B0: malloc (vg_replace_malloc.c:130)
- by 0x80483F1: main (a.c:5)
-
- Syscall param exit(error_code) contains uninitialised byte(s)
- at 0x25A21B44: __GI__exit (in /lib/tls/libc-2.3.3.so)
- by 0x8048426: main (a.c:8)
-]]></programlisting>
-
-<para>... because the program has (a) tried to write uninitialised junk
-from the heap block to the standard output, and (b) passed an
-uninitialised value to <function>exit</function>. Note that the first
-error refers to the memory pointed to by
-<computeroutput>buf</computeroutput> (not
-<computeroutput>buf</computeroutput> itself), but the second error
-refers directly to <computeroutput>exit</computeroutput>'s argument
-<computeroutput>arr2[0]</computeroutput>.</para>
-
-</sect2>
-
-
<sect2 id="mc-manual.overlap"
xreflabel="Overlapping source and destination blocks">
<title>Overlapping source and destination blocks</title>
<para>The following C library functions copy some data from one
memory block to another (or something similar):
-<function>memcpy()</function>,
-<function>strcpy()</function>,
-<function>strncpy()</function>,
-<function>strcat()</function>,
-<function>strncat()</function>.
+<function>memcpy</function>,
+<function>strcpy</function>,
+<function>strncpy</function>,
+<function>strcat</function>,
+<function>strncat</function>.
The blocks pointed to by their <computeroutput>src</computeroutput> and
<computeroutput>dst</computeroutput> pointers aren't allowed to overlap.
-Memcheck checks for this.</para>
+The POSIX standards have wording along the lines "If copying takes place
+between objects that overlap, the behavior is undefined." Therefore,
+Memcheck checks for this.
+</para>
<para>For example:</para>
<programlisting><![CDATA[
@@ -356,18 +364,13 @@
<para>You might think that Memcheck is being overly pedantic reporting
this in the case where <computeroutput>dst</computeroutput> is less than
<computeroutput>src</computeroutput>. For example, the obvious way to
-implement <function>memcpy()</function> is by copying from the first
+implement <function>memcpy</function> is by copying from the first
byte to the last. However, the optimisation guides of some
architectures recommend copying from the last byte down to the first.
-Also, some implementations of <function>memcpy()</function> zero
+Also, some implementations of <function>memcpy</function> zero
<computeroutput>dst</computeroutput> before copying, because zeroing the
destination's cache line(s) can improve performance.</para>
-<para>In addition, for many of these functions, the POSIX standards
-have wording along the lines "If copying takes place between objects
-that overlap, the behavior is undefined." Hence overlapping copies
-violate the standard.</para>
-
<para>The moral of the story is: if you want to write truly portable
code, don't make any assumptions about the language
implementation.</para>
@@ -378,9 +381,9 @@
<sect2 id="mc-manual.leaks" xreflabel="Memory leak detection">
<title>Memory leak detection</title>
-<para>Memcheck keeps track of all memory blocks issued in response to
+<para>Memcheck keeps track of all heap blocks issued in response to
calls to
-<function>malloc</function>/<function>calloc</function>/<function>realloc</function>/<computeroutput>new</computeroutput>.
+<function>malloc</function>/<function>new</function> et al.
So when the program exits, it knows which blocks have not been freed.
</para>
@@ -393,7 +396,7 @@
<para>There are two ways a block can be reached. The first is with a
"start-pointer", i.e. a pointer to the start of the block. The second is with
an "interior-pointer", i.e. a pointer to the middle of the block. There are
-three possibilities we know of:</para>
+three ways we know of that an interior-pointer can occur:</para>
<itemizedlist>
<listitem>
@@ -879,7 +882,7 @@
<para><varname>Overlap</varname>, meaning a
<computeroutput>src</computeroutput> /
<computeroutput>dst</computeroutput> overlap in
- <function>memcpy()</function> or a similar function.</para>
+ <function>memcpy</function> or a similar function.</para>
</listitem>
<listitem>
@@ -894,15 +897,16 @@
system call parameter. No other error kinds have this extra
line.</para>
-<para>The first line of the calling context: for Value and Addr errors,
-it is either the name of the function in which the error occurred, or,
-failing that, the full path of the .so file or executable containing the
-error location. For Free errors, is the name of the function doing the
-freeing (eg, <function>free</function>,
-<function>__builtin_vec_delete</function>, etc). For Overlap errors, is
-the name of the function with the overlapping arguments (eg.
-<function>memcpy()</function>, <function>strcpy()</function>,
-etc).</para>
+<para>The first line of the calling context: for <varname>ValueN</varname>
+and <varname>AddrN</varname> errors, it is either the name of the function
+in which the error occurred, or, failing that, the full path of the
+<filename>.so</filename> file
+or executable containing the error location. For <varname>Free</varname> errors, is the name
+of the function doing the freeing (eg, <function>free</function>,
+<function>__builtin_vec_delete</function>, etc). For
+<varname>Overlap</varname> errors, is the name of the function with the
+overlapping arguments (eg. <function>memcpy</function>,
+<function>strcpy</function>, etc).</para>
<para>Lastly, there's the rest of the calling context.</para>
@@ -937,16 +941,17 @@
memory at a different address, the relevant V bits will be stored back
in the V-bit bitmap.</para>
-<para>In short, each bit in the system has an associated V bit, which
-follows it around everywhere, even inside the CPU. Yes, all the CPU's
-registers (integer, floating point, vector and condition registers) have
-their own V bit vectors.</para>
+<para>In short, each bit in the system has (conceptually) an associated V
+bit, which follows it around everywhere, even inside the CPU. Yes, all the
+CPU's registers (integer, floating point, vector and condition registers)
+have their own V bit vectors. For this to work, Memcheck uses a great deal
+of compression to represent the V bits compactly.</para>
<para>Copying values around does not cause Memcheck to check for, or
report on, errors. However, when a value is used in a way which might
-conceivably affect the outcome of your program's computation, the
-associated V bits are immediately checked. If any of these indicate
-that the value is undefined, an error is reported.</para>
+conceivably affect your program's externally-visible behaviour,
+the associated V bits are immediately checked. If any of these indicate
+that the value is undefined (even partially), an error is reported.</para>
<para>Here's an (admittedly nonsensical) example:</para>
<programlisting><![CDATA[
@@ -1112,7 +1117,8 @@
<para>Each byte in memory has 8 associated V (valid-value) bits,
saying whether or not the byte has a defined value, and a single A
(valid-address) bit, saying whether or not the program currently has
- the right to read/write that address.</para>
+ the right to read/write that address. (But, as mentioned above, heavy
+ use of compression means the overhead is typically less than 25%.)</para>
</listitem>
<listitem>
@@ -1201,12 +1207,8 @@
<listitem>
<para><function>realloc</function>: if the new size is larger than
the old, the new section is addressable but invalid, as with
- <function>malloc</function>.</para>
- </listitem>
-
- <listitem>
- <para>If the new size is smaller, the dropped-off section is
- marked as unaddressable. You may only pass to
+ <function>malloc</function>. If the new size is smaller, the
+ dropped-off section is marked as unaddressable. You may only pass to
<function>realloc</function> a pointer previously issued to you by
<function>malloc</function>/<function>calloc</function>/<function>realloc</function>.</para>
</listitem>
@@ -1293,7 +1295,7 @@
<listitem>
<para><varname>VALGRIND_DO_LEAK_CHECK</varname>: does a full memory leak
- check (like <option>--leak-check=full</option> right now.
+ check (like <option>--leak-check=full</option>) right now.
This is useful for incrementally checking for leaks between arbitrary
places in the program's execution. It has no return value.</para>
</listitem>
@@ -1309,7 +1311,7 @@
<para><varname>VALGRIND_COUNT_LEAKS</varname>: fills in the four
arguments with the number of bytes of memory found by the previous
leak check to be leaked (i.e. the sum of direct leaks and indirect leaks),
- dubious, reachable and suppressed. Again, useful in test harness code,
+ dubious, reachable and suppressed. This is useful in test harness code,
after calling <varname>VALGRIND_DO_LEAK_CHECK</varname> or
<varname>VALGRIND_DO_QUICK_LEAK_CHECK</varname>.</para>
</listitem>
@@ -1369,8 +1371,8 @@
<listitem>
<para>Typically the pool's chunks are drawn from a contiguous
"superblock" acquired through the system
- <function>malloc()</function> or
- <function>mmap()</function>.</para>
+ <function>malloc</function> or
+ <function>mmap</function>.</para>
</listitem>
</itemizedlist>
@@ -1508,7 +1510,7 @@
request informs Memcheck that the pool previously anchored at
address "poolA" has moved to anchor address "poolB". This is a
rare request, typically only needed if you
- <function>realloc()</function> the header of a mempool.</para>
+ <function>realloc</function> the header of a mempool.</para>
<para>No memory-status bits are altered by this request.</para>
</listitem>
@@ -1519,7 +1521,7 @@
previously allocated at address "addrA" within "pool" has been
moved and/or resized, and should be changed to cover the region
[addrB,addrB+size). This is a rare request, typically only needed
- if you <function>realloc()</function> a superblock or wish to
+ if you <function>realloc</function> a superblock or wish to
extend a chunk without changing its memory-status bits.
</para>
<para>No memory-status bits are altered by this request.
@@ -1549,7 +1551,7 @@
<sect1 id="mc-manual.mpiwrap" xreflabel="MPI Wrappers">
<title>Debugging MPI Parallel Programs with Valgrind</title>
-<para> Valgrind supports debugging of distributed-memory applications
+<para>Memcheck supports debugging of distributed-memory applications
which use the MPI message passing standard. This support consists of a
library of wrapper functions for the
<computeroutput>PMPI_*</computeroutput> interface. When incorporated
@@ -1557,7 +1559,7 @@
<computeroutput>LD_PRELOAD</computeroutput>, the wrappers intercept
calls to <computeroutput>PMPI_Send</computeroutput>,
<computeroutput>PMPI_Recv</computeroutput>, etc. They then
-use client requests to inform Valgrind of memory state changes caused
+use client requests to inform Memcheck of memory state changes caused
by the function being wrapped. This reduces the number of false
positives that Memcheck otherwise typically reports for MPI
applications.</para>
@@ -1602,7 +1604,7 @@
<para>If the configure test succeeds, continue in the usual way with
<computeroutput>make</computeroutput> and <computeroutput>make
install</computeroutput>. The final install tree should then contain
-<computeroutput>libmpiwrap.so</computeroutput>.
+<computeroutput>libmpiwrap-<platform>.so</computeroutput>.
</para>
<para>Compile up a test MPI program (eg, MPI hello-world) and try
@@ -1715,12 +1717,8 @@
</sect2>
-<sect2 id="mc-manual.mpiwrap.limitations"
- xreflabel="Abilities and Limitations of MPI Wrappers">
-<title>Abilities and limitations</title>
-
-<sect3 id="mc-manual.mpiwrap.limitations.functions"
- xreflabel="Functions">
+<sect2 id="mc-manual.mpiwrap.limitations.functions"
+ xreflabel="Functions: Abilities and Limitations">
<title>Functions</title>
<para>All MPI2 functions except
@@ -1728,9 +1726,9 @@
<computeroutput>MPI_Wtime</computeroutput> and
<computeroutput>MPI_Pcontrol</computeroutput> have wrappers. The
first two are not wrapped because they return a
-<computeroutput>double</computeroutput>, and Valgrind's
-function-wrap mechanism cannot handle that (it could easily enough be
-extended to). <computeroutput>MPI_Pcontrol</computeroutput> cannot be
+<computeroutput>double</computeroutput>, which Valgrind's
+function-wrap mechanism cannot handle (but it could easily be
+extended to do so). <computeroutput>MPI_Pcontrol</computeroutput> cannot be
wrapped as it has variable arity:
<computeroutput>int MPI_Pcontrol(const int level, ...)</computeroutput></para>
@@ -1783,10 +1781,10 @@
<computeroutput>PMPI_Type_get_envelope</computeroutput>,
<computeroutput>PMPI_Type_get_contents</computeroutput>, and
<computeroutput>PMPI_Type_free</computeroutput>. </para>
-</sect3>
+</sect2>
-<sect3 id="mc-manual.mpiwrap.limitations.types"
- xreflabel="Types">
+<sect2 id="mc-manual.mpiwrap.limitations.types"
+ xreflabel="Types: Abilities and Limitations">
<title>Types</title>
<para> MPI-1.1 structured types are supported, and walked exactly.
@@ -1838,8 +1836,6 @@
wrappers handle each element individually and so there can be a very
large performance cost.</para>
-</sect3>
-
</sect2>
|
|
From: <sv...@va...> - 2009-08-05 05:11:17
|
Author: njn
Date: 2009-08-05 06:11:02 +0100 (Wed, 05 Aug 2009)
New Revision: 10715
Log:
Move command-line option details after the description of Memcheck's error
messages, since that's an order that will make more sense for a newbie.
Modified:
trunk/memcheck/docs/mc-manual.xml
Modified: trunk/memcheck/docs/mc-manual.xml
===================================================================
--- trunk/memcheck/docs/mc-manual.xml 2009-08-05 05:05:15 UTC (rev 10714)
+++ trunk/memcheck/docs/mc-manual.xml 2009-08-05 05:11:02 UTC (rev 10715)
@@ -57,267 +57,14 @@
-<sect1 id="mc-manual.flags"
- xreflabel="Command-line flags specific to Memcheck">
-<title>Command-line flags specific to Memcheck</title>
-
-<!-- start of xi:include in the manpage -->
-<variablelist id="mc.opts.list">
-
- <varlistentry id="opt.leak-check" xreflabel="--leak-check">
- <term>
- <option><![CDATA[--leak-check=<no|summary|yes|full> [default: summary] ]]></option>
- </term>
- <listitem>
- <para>When enabled, search for memory leaks when the client
- program finishes. If set to <varname>summary</varname>, it says how
- many leaks occurred. If set to <varname>full</varname> or
- <varname>yes</varname>, it also gives details of each individual
- leak.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry id="opt.leak-resolution" xreflabel="--leak-resolution">
- <term>
- <option><![CDATA[--leak-resolution=<low|med|high> [default: high] ]]></option>
- </term>
- <listitem>
- <para>When doing leak checking, determines how willing
- Memcheck is to consider different backtraces to
- be the same. When set to <varname>low</varname>, only the first
- two entries need match. When <varname>med</varname>, four entries
- have to match. When <varname>high</varname>, all entries need to
- match; this is consistent with how merging occurs for other kinds of
- errors.</para>
-
- <para>For hardcore leak debugging, you probably want to use
- <option>--leak-resolution=high</option> together with
- <option>--num-callers=40</option> or some such large number.
- </para>
-
- <para>Note that the <option>--leak-resolution</option> setting
- does not affect Memcheck's ability to find
- leaks. It only changes how the results are presented.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry id="opt.show-reachable" xreflabel="--show-reachable">
- <term>
- <option><![CDATA[--show-reachable=<yes|no> [default: no] ]]></option>
- </term>
- <listitem>
- <para>When disabled, the memory leak detector only shows "definitely
- lost" and "possibly lost" blocks. When enabled, the leak detector also
- shows "reachable" and "indirectly lost" blocks. (In other words, it
- shows all blocks, except suppressed ones, so
- <option>--show-all</option> would be a better name for
- it.)</para>
- </listitem>
- </varlistentry>
-
- <varlistentry id="opt.undef-value-errors" xreflabel="--undef-value-errors">
- <term>
- <option><![CDATA[--undef-value-errors=<yes|no> [default: yes] ]]></option>
- </term>
- <listitem>
- <para>Controls whether Memcheck reports
- uses of undefined value errors. Set this to
- <varname>no</varname> if you don't want to see undefined value
- errors. It also has the side effect of speeding up
- memcheck somewhat.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry id="opt.track-origins" xreflabel="--track-origins">
- <term>
- <option><![CDATA[--track-origins=<yes|no> [default: no] ]]></option>
- </term>
- <listitem>
- <para>Controls whether Memcheck tracks
- the origin of uninitialised values. By default, it does not,
- which means that although it can tell you that an
- uninitialised value is being used in a dangerous way, it
- cannot tell you where the uninitialised value came from. This
- often makes it difficult to track down the root problem.
- </para>
- <para>When set
- to <varname>yes</varname>, Memcheck keeps
- track of the origins of all uninitialised values. Then, when
- an uninitialised value error is
- reported, Memcheck will try to show the
- origin of the value. An origin can be one of the following
- four places: a heap block, a stack allocation, a client
- request, or miscellaneous other sources (eg, a call
- to <varname>brk</varname>).
- </para>
- <para>For uninitialised values originating from a heap
- block, Memcheck shows where the block was
- allocated. For uninitialised values originating from a stack
- allocation, Memcheck can tell you which
- function allocated the value, but no more than that -- typically
- it shows you the source location of the opening brace of the
- function. So you should carefully check that all of the
- function's local variables are initialised properly.
- </para>
- <para>Performance overhead: origin tracking is expensive. It
- halves Memcheck's speed and increases
- memory use by a minimum of 100MB, and possibly more.
- Nevertheless it can drastically reduce the effort required to
- identify the root cause of uninitialised value errors, and so
- is often a programmer productivity win, despite running
- more slowly.
- </para>
- <para>Accuracy: Memcheck tracks origins
- quite accurately. To avoid very large space and time
- overheads, some approximations are made. It is possible,
- although unlikely, that Memcheck will report an incorrect origin, or
- not be able to identify any origin.
- </para>
- <para>Note that the combination
- <option>--track-origins=yes</option>
- and <option>--undef-value-errors=no</option> is
- nonsensical. Memcheck checks for and
- rejects this combination at startup.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry id="opt.partial-loads-ok" xreflabel="--partial-loads-ok">
- <term>
- <option><![CDATA[--partial-loads-ok=<yes|no> [default: no] ]]></option>
- </term>
- <listitem>
- <para>Controls how Memcheck handles word-sized,
- word-aligned loads from addresses for which some bytes are
- addressable and others are not. When <varname>yes</varname>, such
- loads do not produce an address error. Instead, loaded bytes
- originating from illegal addresses are marked as uninitialised, and
- those corresponding to legal addresses are handled in the normal
- way.</para>
-
- <para>When <varname>no</varname>, loads from partially invalid
- addresses are treated the same as loads from completely invalid
- addresses: an illegal-address error is issued, and the resulting
- bytes are marked as initialised.</para>
-
- <para>Note that code that behaves in this way is in violation of
- the the ISO C/C++ standards, and should be considered broken. If
- at all possible, such code should be fixed. This flag should be
- used only as a last resort.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry id="opt.freelist-vol" xreflabel="--freelist-vol">
- <term>
- <option><![CDATA[--freelist-vol=<number> [default: 10000000] ]]></option>
- </term>
- <listitem>
- <para>When the client program releases memory using
- <function>free</function> (in <literal>C</literal>) or
- <computeroutput>delete</computeroutput>
- (<literal>C++</literal>), 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 defer as
- long as possible the point at which freed-up memory comes back
- into circulation. This increases the chance that
- Memcheck will be able to detect invalid
- accesses to blocks for some significant period of time after they
- have been freed.</para>
-
- <para>This flag specifies the maximum total size, in bytes, of the
- blocks in the queue. The default value is ten million bytes.
- Increasing this increases the total amount of memory used by
- Memcheck but may detect invalid uses of freed
- blocks which would otherwise go undetected.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry id="opt.workaround-gcc296-bugs" xreflabel="--workaround-gcc296-bugs">
- <term>
- <option><![CDATA[--workaround-gcc296-bugs=<yes|no> [default: no] ]]></option>
- </term>
- <listitem>
- <para>When enabled, assume that reads and writes some small
- distance below the stack pointer 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 ancient
- Linux distributions (RedHat 7.X) and so you may need to use this
- flag. Do not use it if you do not have to, as it can cause real
- errors to be overlooked. A better alternative is to use a more
- recent GCC in which this bug is fixed.</para>
-
- <para>You may also need to use this flag when working with
- GCC 3.X or 4.X on 32-bit PowerPC Linux. This is because
- GCC generates code which occasionally accesses below the
- stack pointer, particularly for floating-point to/from integer
- conversions. This is in violation of the 32-bit PowerPC ELF
- specification, which makes no provision for locations below the
- stack pointer to be accessible.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry id="opt.ignore-ranges" xreflabel="--ignore-ranges">
- <term>
- <option><![CDATA[--ignore-ranges=0xPP-0xQQ[,0xRR-0xSS] ]]></option>
- </term>
- <listitem>
- <para>Any ranges listed in this option (and multiple ranges can be
- specified, separated by commas) will be ignored by Memcheck's
- addressability checking.
- </listitem>
- </varlistentry>
-
- <varlistentry id="opt.malloc-fill" xreflabel="--malloc-fill">
- <term>
- <option><![CDATA[--malloc-fill=<hexnumber> ]]></option>
- </term>
- <listitem>
- <para>Fills blocks allocated
- by <computeroutput>malloc</computeroutput>,
- <computeroutput>new</computeroutput>, etc, but not
- by <computeroutput>calloc</computeroutput>, with the specified
- byte. This can be useful when trying to shake out obscure
- memory corruption problems. The allocated area is still
- regarded by Memcheck as undefined -- this flag only affects its
- contents.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry id="opt.free-fill" xreflabel="--free-fill">
- <term>
- <option><![CDATA[--free-fill=<hexnumber> ]]></option>
- </term>
- <listitem>
- <para>Fills blocks freed
- by <computeroutput>free</computeroutput>,
- <computeroutput>delete</computeroutput>, etc, with the
- specified byte. This can be useful when trying to shake out
- obscure memory corruption problems. The freed area is still
- regarded by Memcheck as not valid for access -- this flag only
- affects its contents.
- </para>
- </listitem>
- </varlistentry>
-
-</variablelist>
-<!-- end of xi:include in the manpage -->
-
-</sect1>
-
-
<sect1 id="mc-manual.errormsgs"
xreflabel="Explanation of error messages from Memcheck">
<title>Explanation of error messages from Memcheck</title>
-<para>Despite considerable sophistication under the hood, Memcheck can
-only really detect two kinds of errors: use of illegal addresses, and
-use of undefined values. Nevertheless, this is enough to help you
-discover all sorts of memory-management problems in your code. This
-section presents a quick summary of what error messages mean. The
-precise behaviour of the error-checking machinery is described in
-<xref linkend="mc-manual.machine"/>.</para>
+<para>Memcheck issues a range of error messages. This section presents a
+quick summary of what error messages mean. The precise behaviour of the
+error-checking machinery is described in <xref
+linkend="mc-manual.machine"/>.</para>
<sect2 id="mc-manual.badrw"
@@ -824,6 +571,256 @@
+<sect1 id="mc-manual.flags"
+ xreflabel="Command-line flags specific to Memcheck">
+<title>Command-line flags specific to Memcheck</title>
+
+<!-- start of xi:include in the manpage -->
+<variablelist id="mc.opts.list">
+
+ <varlistentry id="opt.leak-check" xreflabel="--leak-check">
+ <term>
+ <option><![CDATA[--leak-check=<no|summary|yes|full> [default: summary] ]]></option>
+ </term>
+ <listitem>
+ <para>When enabled, search for memory leaks when the client
+ program finishes. If set to <varname>summary</varname>, it says how
+ many leaks occurred. If set to <varname>full</varname> or
+ <varname>yes</varname>, it also gives details of each individual
+ leak.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="opt.leak-resolution" xreflabel="--leak-resolution">
+ <term>
+ <option><![CDATA[--leak-resolution=<low|med|high> [default: high] ]]></option>
+ </term>
+ <listitem>
+ <para>When doing leak checking, determines how willing
+ Memcheck is to consider different backtraces to
+ be the same for the purposes of merging multiple leaks into a single
+ leak report. When set to <varname>low</varname>, only the first
+ two entries need match. When <varname>med</varname>, four entries
+ have to match. When <varname>high</varname>, all entries need to
+ match.</para>
+
+ <para>For hardcore leak debugging, you probably want to use
+ <option>--leak-resolution=high</option> together with
+ <option>--num-callers=40</option> or some such large number.
+ </para>
+
+ <para>Note that the <option>--leak-resolution</option> setting
+ does not affect Memcheck's ability to find
+ leaks. It only changes how the results are presented.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="opt.show-reachable" xreflabel="--show-reachable">
+ <term>
+ <option><![CDATA[--show-reachable=<yes|no> [default: no] ]]></option>
+ </term>
+ <listitem>
+ <para>When disabled, the memory leak detector only shows "definitely
+ lost" and "possibly lost" blocks. When enabled, the leak detector also
+ shows "reachable" and "indirectly lost" blocks. (In other words, it
+ shows all blocks, except suppressed ones, so
+ <option>--show-all</option> would be a better name for
+ it.)</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="opt.undef-value-errors" xreflabel="--undef-value-errors">
+ <term>
+ <option><![CDATA[--undef-value-errors=<yes|no> [default: yes] ]]></option>
+ </term>
+ <listitem>
+ <para>Controls whether Memcheck reports
+ uses of undefined value errors. Set this to
+ <varname>no</varname> if you don't want to see undefined value
+ errors. It also has the side effect of speeding up
+ Memcheck somewhat.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="opt.track-origins" xreflabel="--track-origins">
+ <term>
+ <option><![CDATA[--track-origins=<yes|no> [default: no] ]]></option>
+ </term>
+ <listitem>
+ <para>Controls whether Memcheck tracks
+ the origin of uninitialised values. By default, it does not,
+ which means that although it can tell you that an
+ uninitialised value is being used in a dangerous way, it
+ cannot tell you where the uninitialised value came from. This
+ often makes it difficult to track down the root problem.
+ </para>
+ <para>When set
+ to <varname>yes</varname>, Memcheck keeps
+ track of the origins of all uninitialised values. Then, when
+ an uninitialised value error is
+ reported, Memcheck will try to show the
+ origin of the value. An origin can be one of the following
+ four places: a heap block, a stack allocation, a client
+ request, or miscellaneous other sources (eg, a call
+ to <varname>brk</varname>).
+ </para>
+ <para>For uninitialised values originating from a heap
+ block, Memcheck shows where the block was
+ allocated. For uninitialised values originating from a stack
+ allocation, Memcheck can tell you which
+ function allocated the value, but no more than that -- typically
+ it shows you the source location of the opening brace of the
+ function. So you should carefully check that all of the
+ function's local variables are initialised properly.
+ </para>
+ <para>Performance overhead: origin tracking is expensive. It
+ halves Memcheck's speed and increases
+ memory use by a minimum of 100MB, and possibly more.
+ Nevertheless it can drastically reduce the effort required to
+ identify the root cause of uninitialised value errors, and so
+ is often a programmer productivity win, despite running
+ more slowly.
+ </para>
+ <para>Accuracy: Memcheck tracks origins
+ quite accurately. To avoid very large space and time
+ overheads, some approximations are made. It is possible,
+ although unlikely, that Memcheck will report an incorrect origin, or
+ not be able to identify any origin.
+ </para>
+ <para>Note that the combination
+ <option>--track-origins=yes</option>
+ and <option>--undef-value-errors=no</option> is
+ nonsensical. Memcheck checks for and
+ rejects this combination at startup.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="opt.partial-loads-ok" xreflabel="--partial-loads-ok">
+ <term>
+ <option><![CDATA[--partial-loads-ok=<yes|no> [default: no] ]]></option>
+ </term>
+ <listitem>
+ <para>Controls how Memcheck handles word-sized,
+ word-aligned loads from addresses for which some bytes are
+ addressable and others are not. When <varname>yes</varname>, such
+ loads do not produce an address error. Instead, loaded bytes
+ originating from illegal addresses are marked as uninitialised, and
+ those corresponding to legal addresses are handled in the normal
+ way.</para>
+
+ <para>When <varname>no</varname>, loads from partially invalid
+ addresses are treated the same as loads from completely invalid
+ addresses: an illegal-address error is issued, and the resulting
+ bytes are marked as initialised.</para>
+
+ <para>Note that code that behaves in this way is in violation of
+ the the ISO C/C++ standards, and should be considered broken. If
+ at all possible, such code should be fixed. This flag should be
+ used only as a last resort.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="opt.freelist-vol" xreflabel="--freelist-vol">
+ <term>
+ <option><![CDATA[--freelist-vol=<number> [default: 10000000] ]]></option>
+ </term>
+ <listitem>
+ <para>When the client program releases memory using
+ <function>free</function> (in <literal>C</literal>) or
+ <computeroutput>delete</computeroutput>
+ (<literal>C++</literal>), 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 defer as
+ long as possible the point at which freed-up memory comes back
+ into circulation. This increases the chance that
+ Memcheck will be able to detect invalid
+ accesses to blocks for some significant period of time after they
+ have been freed.</para>
+
+ <para>This flag specifies the maximum total size, in bytes, of the
+ blocks in the queue. The default value is ten million bytes.
+ Increasing this increases the total amount of memory used by
+ Memcheck but may detect invalid uses of freed
+ blocks which would otherwise go undetected.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="opt.workaround-gcc296-bugs" xreflabel="--workaround-gcc296-bugs">
+ <term>
+ <option><![CDATA[--workaround-gcc296-bugs=<yes|no> [default: no] ]]></option>
+ </term>
+ <listitem>
+ <para>When enabled, assume that reads and writes some small
+ distance below the stack pointer 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 ancient
+ Linux distributions (RedHat 7.X) and so you may need to use this
+ flag. Do not use it if you do not have to, as it can cause real
+ errors to be overlooked. A better alternative is to use a more
+ recent GCC in which this bug is fixed.</para>
+
+ <para>You may also need to use this flag when working with
+ GCC 3.X or 4.X on 32-bit PowerPC Linux. This is because
+ GCC generates code which occasionally accesses below the
+ stack pointer, particularly for floating-point to/from integer
+ conversions. This is in violation of the 32-bit PowerPC ELF
+ specification, which makes no provision for locations below the
+ stack pointer to be accessible.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="opt.ignore-ranges" xreflabel="--ignore-ranges">
+ <term>
+ <option><![CDATA[--ignore-ranges=0xPP-0xQQ[,0xRR-0xSS] ]]></option>
+ </term>
+ <listitem>
+ <para>Any ranges listed in this option (and multiple ranges can be
+ specified, separated by commas) will be ignored by Memcheck's
+ addressability checking.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="opt.malloc-fill" xreflabel="--malloc-fill">
+ <term>
+ <option><![CDATA[--malloc-fill=<hexnumber> ]]></option>
+ </term>
+ <listitem>
+ <para>Fills blocks allocated
+ by <computeroutput>malloc</computeroutput>,
+ <computeroutput>new</computeroutput>, etc, but not
+ by <computeroutput>calloc</computeroutput>, with the specified
+ byte. This can be useful when trying to shake out obscure
+ memory corruption problems. The allocated area is still
+ regarded by Memcheck as undefined -- this flag only affects its
+ contents.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="opt.free-fill" xreflabel="--free-fill">
+ <term>
+ <option><![CDATA[--free-fill=<hexnumber> ]]></option>
+ </term>
+ <listitem>
+ <para>Fills blocks freed
+ by <computeroutput>free</computeroutput>,
+ <computeroutput>delete</computeroutput>, etc, with the
+ specified byte value. This can be useful when trying to shake out
+ obscure memory corruption problems. The freed area is still
+ regarded by Memcheck as not valid for access -- this flag only
+ affects its contents.
+ </para>
+ </listitem>
+ </varlistentry>
+
+</variablelist>
+<!-- end of xi:include in the manpage -->
+
+</sect1>
+
+
<sect1 id="mc-manual.suppfiles" xreflabel="Writing suppression files">
<title>Writing suppression files</title>
|
|
From: <sv...@va...> - 2009-08-05 05:05:29
|
Author: njn
Date: 2009-08-05 06:05:15 +0100 (Wed, 05 Aug 2009)
New Revision: 10714
Log:
Augment a comment.
Modified:
trunk/memcheck/mc_main.c
Modified: trunk/memcheck/mc_main.c
===================================================================
--- trunk/memcheck/mc_main.c 2009-08-05 04:57:44 UTC (rev 10713)
+++ trunk/memcheck/mc_main.c 2009-08-05 05:05:15 UTC (rev 10714)
@@ -5780,6 +5780,12 @@
// - Telying on the zeroed-ness of whole brk'd pages is pretty grotty... I
// doubt most programmers know the above information.
// So I'm not terribly unhappy with marking it as undefined. --njn.
+ //
+ // [More: I think most of what John said only applies to sbrk(). It seems
+ // that brk() always deals in whole pages. And since this event deals
+ // directly with brk(), not with sbrk(), perhaps it would be reasonable to
+ // just mark all memory it allocates as defined.]
+ //
VG_(track_new_mem_brk) ( make_mem_undefined_w_tid );
VG_(track_new_mem_mmap) ( mc_new_mem_mmap );
|
|
From: <sv...@va...> - 2009-08-05 04:57:57
|
Author: njn
Date: 2009-08-05 05:57:44 +0100 (Wed, 05 Aug 2009)
New Revision: 10713
Log:
Added documentation for --ignore-ranges. It's not very good, though, if
anyone can explain clearly why it's useful and wants to add that information
that would be helpful.
Modified:
trunk/memcheck/docs/mc-manual.xml
Modified: trunk/memcheck/docs/mc-manual.xml
===================================================================
--- trunk/memcheck/docs/mc-manual.xml 2009-08-05 04:54:51 UTC (rev 10712)
+++ trunk/memcheck/docs/mc-manual.xml 2009-08-05 04:57:44 UTC (rev 10713)
@@ -257,6 +257,17 @@
</listitem>
</varlistentry>
+ <varlistentry id="opt.ignore-ranges" xreflabel="--ignore-ranges">
+ <term>
+ <option><![CDATA[--ignore-ranges=0xPP-0xQQ[,0xRR-0xSS] ]]></option>
+ </term>
+ <listitem>
+ <para>Any ranges listed in this option (and multiple ranges can be
+ specified, separated by commas) will be ignored by Memcheck's
+ addressability checking.
+ </listitem>
+ </varlistentry>
+
<varlistentry id="opt.malloc-fill" xreflabel="--malloc-fill">
<term>
<option><![CDATA[--malloc-fill=<hexnumber> ]]></option>
|
|
From: <sv...@va...> - 2009-08-05 04:55:05
|
Author: njn
Date: 2009-08-05 05:54:51 +0100 (Wed, 05 Aug 2009)
New Revision: 10712
Log:
Put Memcheck's command line options in the manual in the same order as its
usage message.
Modified:
trunk/memcheck/docs/mc-manual.xml
Modified: trunk/memcheck/docs/mc-manual.xml
===================================================================
--- trunk/memcheck/docs/mc-manual.xml 2009-08-05 04:04:53 UTC (rev 10711)
+++ trunk/memcheck/docs/mc-manual.xml 2009-08-05 04:54:51 UTC (rev 10712)
@@ -64,6 +64,57 @@
<!-- start of xi:include in the manpage -->
<variablelist id="mc.opts.list">
+ <varlistentry id="opt.leak-check" xreflabel="--leak-check">
+ <term>
+ <option><![CDATA[--leak-check=<no|summary|yes|full> [default: summary] ]]></option>
+ </term>
+ <listitem>
+ <para>When enabled, search for memory leaks when the client
+ program finishes. If set to <varname>summary</varname>, it says how
+ many leaks occurred. If set to <varname>full</varname> or
+ <varname>yes</varname>, it also gives details of each individual
+ leak.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="opt.leak-resolution" xreflabel="--leak-resolution">
+ <term>
+ <option><![CDATA[--leak-resolution=<low|med|high> [default: high] ]]></option>
+ </term>
+ <listitem>
+ <para>When doing leak checking, determines how willing
+ Memcheck is to consider different backtraces to
+ be the same. When set to <varname>low</varname>, only the first
+ two entries need match. When <varname>med</varname>, four entries
+ have to match. When <varname>high</varname>, all entries need to
+ match; this is consistent with how merging occurs for other kinds of
+ errors.</para>
+
+ <para>For hardcore leak debugging, you probably want to use
+ <option>--leak-resolution=high</option> together with
+ <option>--num-callers=40</option> or some such large number.
+ </para>
+
+ <para>Note that the <option>--leak-resolution</option> setting
+ does not affect Memcheck's ability to find
+ leaks. It only changes how the results are presented.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="opt.show-reachable" xreflabel="--show-reachable">
+ <term>
+ <option><![CDATA[--show-reachable=<yes|no> [default: no] ]]></option>
+ </term>
+ <listitem>
+ <para>When disabled, the memory leak detector only shows "definitely
+ lost" and "possibly lost" blocks. When enabled, the leak detector also
+ shows "reachable" and "indirectly lost" blocks. (In other words, it
+ shows all blocks, except suppressed ones, so
+ <option>--show-all</option> would be a better name for
+ it.)</para>
+ </listitem>
+ </varlistentry>
+
<varlistentry id="opt.undef-value-errors" xreflabel="--undef-value-errors">
<term>
<option><![CDATA[--undef-value-errors=<yes|no> [default: yes] ]]></option>
@@ -132,54 +183,28 @@
</listitem>
</varlistentry>
- <varlistentry id="opt.leak-check" xreflabel="--leak-check">
+ <varlistentry id="opt.partial-loads-ok" xreflabel="--partial-loads-ok">
<term>
- <option><![CDATA[--leak-check=<no|summary|yes|full> [default: summary] ]]></option>
+ <option><![CDATA[--partial-loads-ok=<yes|no> [default: no] ]]></option>
</term>
<listitem>
- <para>When enabled, search for memory leaks when the client
- program finishes. If set to <varname>summary</varname>, it says how
- many leaks occurred. If set to <varname>full</varname> or
- <varname>yes</varname>, it also gives details of each individual
- leak.</para>
- </listitem>
- </varlistentry>
+ <para>Controls how Memcheck handles word-sized,
+ word-aligned loads from addresses for which some bytes are
+ addressable and others are not. When <varname>yes</varname>, such
+ loads do not produce an address error. Instead, loaded bytes
+ originating from illegal addresses are marked as uninitialised, and
+ those corresponding to legal addresses are handled in the normal
+ way.</para>
- <varlistentry id="opt.show-reachable" xreflabel="--show-reachable">
- <term>
- <option><![CDATA[--show-reachable=<yes|no> [default: no] ]]></option>
- </term>
- <listitem>
- <para>When disabled, the memory leak detector only shows "definitely
- lost" and "possibly lost" blocks. When enabled, the leak detector also
- shows "reachable" and "indirectly lost" blocks. (In other words, it
- shows all blocks, except suppressed ones, so
- <option>--show-all</option> would be a better name for
- it.)</para>
- </listitem>
- </varlistentry>
+ <para>When <varname>no</varname>, loads from partially invalid
+ addresses are treated the same as loads from completely invalid
+ addresses: an illegal-address error is issued, and the resulting
+ bytes are marked as initialised.</para>
- <varlistentry id="opt.leak-resolution" xreflabel="--leak-resolution">
- <term>
- <option><![CDATA[--leak-resolution=<low|med|high> [default: high] ]]></option>
- </term>
- <listitem>
- <para>When doing leak checking, determines how willing
- Memcheck is to consider different backtraces to
- be the same. When set to <varname>low</varname>, only the first
- two entries need match. When <varname>med</varname>, four entries
- have to match. When <varname>high</varname>, all entries need to
- match; this is consistent with how merging occurs for other kinds of
- errors.</para>
-
- <para>For hardcore leak debugging, you probably want to use
- <option>--leak-resolution=high</option> together with
- <option>--num-callers=40</option> or some such large number.
- </para>
-
- <para>Note that the <option>--leak-resolution</option> setting
- does not affect Memcheck's ability to find
- leaks. It only changes how the results are presented.</para>
+ <para>Note that code that behaves in this way is in violation of
+ the the ISO C/C++ standards, and should be considered broken. If
+ at all possible, such code should be fixed. This flag should be
+ used only as a last resort.</para>
</listitem>
</varlistentry>
@@ -232,31 +257,6 @@
</listitem>
</varlistentry>
- <varlistentry id="opt.partial-loads-ok" xreflabel="--partial-loads-ok">
- <term>
- <option><![CDATA[--partial-loads-ok=<yes|no> [default: no] ]]></option>
- </term>
- <listitem>
- <para>Controls how Memcheck handles word-sized,
- word-aligned loads from addresses for which some bytes are
- addressable and others are not. When <varname>yes</varname>, such
- loads do not produce an address error. Instead, loaded bytes
- originating from illegal addresses are marked as uninitialised, and
- those corresponding to legal addresses are handled in the normal
- way.</para>
-
- <para>When <varname>no</varname>, loads from partially invalid
- addresses are treated the same as loads from completely invalid
- addresses: an illegal-address error is issued, and the resulting
- bytes are marked as initialised.</para>
-
- <para>Note that code that behaves in this way is in violation of
- the the ISO C/C++ standards, and should be considered broken. If
- at all possible, such code should be fixed. This flag should be
- used only as a last resort.</para>
- </listitem>
- </varlistentry>
-
<varlistentry id="opt.malloc-fill" xreflabel="--malloc-fill">
<term>
<option><![CDATA[--malloc-fill=<hexnumber> ]]></option>
|
|
From: <sv...@va...> - 2009-08-05 04:05:07
|
Author: njn Date: 2009-08-05 05:04:53 +0100 (Wed, 05 Aug 2009) New Revision: 10711 Log: More Massif manual tweaks. Modified: trunk/massif/docs/ms-manual.xml Modified: trunk/massif/docs/ms-manual.xml =================================================================== --- trunk/massif/docs/ms-manual.xml 2009-08-05 02:02:31 UTC (rev 10710) +++ trunk/massif/docs/ms-manual.xml 2009-08-05 04:04:53 UTC (rev 10711) @@ -255,17 +255,30 @@ peak snapshot is a detailed snapshot, and records the point where memory consumption was greatest. The peak snapshot is represented in the graph by a bar consisting of '#' characters. The text at the bottom shows -that snapshot 14 was the peak. Note that for tiny programs that never -deallocate heap memory, Massif will not record a peak snapshot.</para> +that snapshot 14 was the peak.</para> -<para>Some more details about the peak: the peak is determined by looking -at every allocation, i.e. it is <emphasis>not</emphasis> just the peak among -the regular snapshots. However, recording the true peak can be expensive, and -so by default Massif records a peak whose size is within 1% of the size of -the true peak. See the description of the -<option>--peak-inaccuracy</option> option below for more -details.</para> +<para>Massif's determination of when the peak occurred can be wrong, for +two reasons.</para> +<itemizedlist> + <listitem><para>Peak snapshots are only ever taken after a deallocation + happens. This avoids lots of unnecessary peak snapshot recordings + (imagine what happens if your program allocates a lot of heap blocks in + succession, hitting a new peak every time). But it means that if your + program never deallocates any blocks, no peak will be recorded. It also + means that if your program does deallocate blocks but later allocates to a + higher peak without subsequently deallocating, the reported peak will be + too low. + </para> + </listitem> + + <listitem><para>Even with this behaviour, recording the peak accurately + is slow. So by default Massif records a peak whose size is within 1% of + the size of the true peak. This inaccuracy in the peak measurement can be + changed with the <option>--peak-inaccuracy</option> option.</para> + </listitem> +</itemizedlist> + <para>The following graph is from an execution of Konqueror, the KDE web browser. It shows what graphs for larger programs look like.</para> <screen><![CDATA[ |
|
From: Tom H. <th...@cy...> - 2009-08-05 02:48:58
|
Nightly build on vauxhall ( x86_64, Fedora 11 ) Started at 2009-08-05 03:20:03 BST Ended at 2009-08-05 03:48:36 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 530 tests, 11 stderr failures, 0 stdout failures, 0 post failures == memcheck/tests/linux/stack_switch (stderr) memcheck/tests/long_namespace_xml (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc23_bogus_condwait (stderr) drd/tests/boost_thread (stderr) drd/tests/qt4_mutex (stderr) drd/tests/qt4_rwlock (stderr) drd/tests/qt4_semaphore (stderr) drd/tests/tc20_verifywrap2 (stderr) exp-ptrcheck/tests/bad_percentify (stderr) |
|
From: Tom H. <th...@cy...> - 2009-08-05 02:48:02
|
Nightly build on lloyd ( x86_64, Fedora 7 ) Started at 2009-08-05 03:05:03 BST Ended at 2009-08-05 03:47:40 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 520 tests, 1 stderr failure, 0 stdout failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) |
|
From: Tom H. <th...@cy...> - 2009-08-05 02:31:04
|
Nightly build on mg ( x86_64, Fedora 9 ) Started at 2009-08-05 03:10:04 BST Ended at 2009-08-05 03:30:44 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 527 tests, 1 stderr failure, 0 stdout failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) |
|
From: <sv...@va...> - 2009-08-05 02:03:02
|
Author: njn
Date: 2009-08-05 03:02:31 +0100 (Wed, 05 Aug 2009)
New Revision: 10710
Log:
Comment and docs wibbles.
Modified:
trunk/massif/docs/ms-manual.xml
trunk/massif/ms_main.c
Modified: trunk/massif/docs/ms-manual.xml
===================================================================
--- trunk/massif/docs/ms-manual.xml 2009-08-04 07:02:54 UTC (rev 10709)
+++ trunk/massif/docs/ms-manual.xml 2009-08-05 02:02:31 UTC (rev 10710)
@@ -645,7 +645,20 @@
which can fill up the allocation trees with uninteresting information.
This option can be specified multiple times on the command line, to
name multiple functions.</para>
-
+
+ <para>Note that the named function will only be treated this way if it is
+ the top entry in a stack trace, or just below another function treated
+ this way. For example, if you have a function
+ <function>malloc1</function> that wraps <function>malloc</function>,
+ and <function>malloc2</function> that wraps
+ <function>malloc1</function>, just specifying
+ <option>--alloc-fn=malloc2</option> will have no effect. You need to
+ specify <option>--alloc-fn=malloc1</option> as well. This is a little
+ inconvenient, but the reason is that checking for allocation functions
+ is slow, and it saves a lot of time if Massif can stop looking through
+ the stack trace entries as soon as it finds one that doesn't match
+ rather than having to continue through all the entries.</para>
+
<para>Note that C++ names are demangled. Note also that overloaded
C++ names must be written in full. Single quotes may be necessary to
prevent the shell from breaking them up. For example:
Modified: trunk/massif/ms_main.c
===================================================================
--- trunk/massif/ms_main.c 2009-08-04 07:02:54 UTC (rev 10709)
+++ trunk/massif/ms_main.c 2009-08-05 02:02:31 UTC (rev 10710)
@@ -871,14 +871,11 @@
// If the original stack trace is smaller than asked-for, redo=False.
if (n_ips < clo_depth + overestimate) { redo = False; }
- // If it's a non-custom block, we will always remove the first stack
- // trace entry (which will be one of malloc, __builtin_new, etc).
- n_alloc_fns_removed = ( is_custom_alloc ? 0 : 1 );
-
// Filter out alloc fns. If it's a non-custom block, we remove the
// first entry (which will be one of malloc, __builtin_new, etc)
// without looking at it, because VG_(get_fnname) is expensive (it
// involves calls to VG_(malloc)/VG_(free)).
+ n_alloc_fns_removed = ( is_custom_alloc ? 0 : 1 );
for (i = n_alloc_fns_removed; i < n_ips; i++) {
if (VG_(get_fnname)(ips[i], buf, BUF_LEN)) {
if (is_member_fn(alloc_fns, buf)) {
|