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
(6) |
2
(4) |
3
(4) |
4
(4) |
|
5
(6) |
6
(9) |
7
(4) |
8
(15) |
9
(6) |
10
(6) |
11
(22) |
|
12
(12) |
13
(9) |
14
(4) |
15
(11) |
16
(8) |
17
(4) |
18
(6) |
|
19
(6) |
20
(15) |
21
(9) |
22
(9) |
23
(14) |
24
(7) |
25
(7) |
|
26
(8) |
27
(11) |
28
(4) |
29
(4) |
30
(12) |
31
(7) |
|
|
From: Tom H. <th...@cy...> - 2008-10-25 03:06:14
|
Nightly build on lloyd ( x86_64, Fedora 7 ) started at 2008-10-25 03:05:06 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 == 461 tests, 12 stderr failures, 3 stdout failures, 0 post failures == exp-ptrcheck/tests/base (stderr) exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc22_exit_w_lock (stderr) memcheck/tests/file_locking (stderr) memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/scalar (stderr) none/tests/blockfault (stderr) none/tests/cmdline2 (stdout) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2008-10-25 02:47:43
|
Nightly build on trojan ( x86_64, Fedora Core 6 ) started at 2008-10-25 03:25:06 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 == 465 tests, 14 stderr failures, 5 stdout failures, 0 post failures == exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) memcheck/tests/file_locking (stderr) memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/bug133694 (stdout) memcheck/tests/x86/bug133694 (stderr) memcheck/tests/x86/scalar (stderr) none/tests/blockfault (stderr) none/tests/cmdline1 (stdout) none/tests/cmdline2 (stdout) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2008-10-25 02:27:36
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2008-10-25 03:00:02 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 == 467 tests, 34 stderr failures, 4 stdout failures, 0 post failures == drd/tests/pth_cancel_locked (stderr) exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/hackedbz2 (stderr) helgrind/tests/hg01_all_ok (stderr) helgrind/tests/hg02_deadlock (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc14_laog_dinphils (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) memcheck/tests/file_locking (stderr) memcheck/tests/malloc_free_fill (stderr) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/varinfo6 (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/amd64/insn_ssse3 (stdout) none/tests/amd64/insn_ssse3 (stderr) none/tests/amd64/ssse3_misaligned (stderr) none/tests/blockfault (stderr) none/tests/cmdline2 (stdout) none/tests/fdleak_fcntl (stderr) none/tests/mremap2 (stdout) none/tests/x86/insn_ssse3 (stdout) none/tests/x86/insn_ssse3 (stderr) none/tests/x86/ssse3_misaligned (stderr) |
|
From: <sv...@va...> - 2008-10-24 19:17:57
|
Author: weidendo
Date: 2008-10-24 20:17:52 +0100 (Fri, 24 Oct 2008)
New Revision: 8706
Log:
Update
Modified:
trunk/docs/internals/3_3_BUGSTATUS.txt
Modified: trunk/docs/internals/3_3_BUGSTATUS.txt
===================================================================
--- trunk/docs/internals/3_3_BUGSTATUS.txt 2008-10-24 18:50:04 UTC (rev 8705)
+++ trunk/docs/internals/3_3_BUGSTATUS.txt 2008-10-24 19:17:52 UTC (rev 8706)
@@ -193,4 +193,6 @@
r8154 r8155 Mgd n-i-bz Massif/Cachegrind output corruption when
programs fork
+r8704 pending 166581 Callgrind output corruption when program forks
+
vx1853 vx1854 33 n-i-bz regalloc: don't incorrectly omit spill stores
|
|
From: <sv...@va...> - 2008-10-24 18:50:10
|
Author: weidendo
Date: 2008-10-24 19:50:04 +0100 (Fri, 24 Oct 2008)
New Revision: 8705
Log:
Callgrind manual: add section on client requests and note about fork().
Modified:
trunk/callgrind/docs/cl-manual.xml
Modified: trunk/callgrind/docs/cl-manual.xml
===================================================================
--- trunk/callgrind/docs/cl-manual.xml 2008-10-24 18:50:00 UTC (rev 8704)
+++ trunk/callgrind/docs/cl-manual.xml 2008-10-24 18:50:04 UTC (rev 8705)
@@ -197,7 +197,7 @@
<computeroutput>callgrind_control -i on</computeroutput> just before the
interesting code section is executed. To exactly specify
the code position where profiling should start, use the client request
- <computeroutput>CALLGRIND_START_INSTRUMENTATION</computeroutput>.</para>
+ <computeroutput><xref linkend="cr.start-instr"/></computeroutput>.</para>
<para>If you want to be able to see assembly code level annotation, specify
<option><xref linkend="opt.dump-instr"/>=yes</option>. This will produce
@@ -292,18 +292,13 @@
<listitem>
<para><command>Program controlled dumping.</command>
- Put <screen><![CDATA[#include <valgrind/callgrind.h>]]></screen>
- into your source and add
- <computeroutput>CALLGRIND_DUMP_STATS;</computeroutput> when you
- want a dump to happen. Use
- <computeroutput>CALLGRIND_ZERO_STATS;</computeroutput> to only
- zero cost centers.</para>
- <para>In Valgrind terminology, this method is called "Client
- requests". The given macros generate a special instruction
- pattern with no effect at all (i.e. a NOP). When run under
- Valgrind, the CPU simulation engine detects the special
- instruction pattern and triggers special actions like the ones
- described above.</para>
+ Insert
+ <computeroutput><xref linkend="cr.dump-stats"/>;</computeroutput>
+ at the position in your code where you want a profile dump to happen. Use
+ <computeroutput><xref linkend="cr.zero-stats"/>;</computeroutput> to only
+ zero profile counters.
+ See <xref linkend="cl-manual.clientrequests"/> for more information on
+ Callgrind specific client requests.</para>
</listitem>
</itemizedlist>
@@ -338,8 +333,8 @@
with <screen>callgrind_control -i on</screen>
and off by specifying "off" instead of "on".
Furthermore, instrumentation state can be programatically changed with
- the macros <computeroutput>CALLGRIND_START_INSTRUMENTATION;</computeroutput>
- and <computeroutput>CALLGRIND_STOP_INSTRUMENTATION;</computeroutput>.
+ the macros <computeroutput><xref linkend="cr.start-instr"/>;</computeroutput>
+ and <computeroutput><xref linkend="cr.stop-instr"/>;</computeroutput>.
</para>
<para>In addition to enabling instrumentation, you must also enable
@@ -471,6 +466,27 @@
</sect2>
+ <sect2 id="cl-manual.forkingprograms" xreflabel="Forking Programs">
+ <title>Forking Programs</title>
+
+ <para>If your program forks, the child will inherit all the profiling
+ data that has been gathered for the parent. To start with empty profile
+ counter values in the child, the client request
+ <computeroutput><xref linkend="cr.zero-stats"/>;</computeroutput>
+ can be inserted into code to be executed by the child, directly after
+ <computeroutput>fork()</computeroutput>.</para>
+
+ <para>However, you will have to make sure that the output file format string
+ (controlled by <option>--callgrind-out-file</option>) does contain
+ <option>%p</option> (which is true by default). Otherwise, the
+ outputs from the parent and child will overwrite each other or will be
+ intermingled, which almost certainly is not what you want.</para>
+
+ <para>You will be able to control the new child independently from
+ the parent via <computeroutput>callgrind_control</computeroutput>.</para>
+
+ </sect2>
+
</sect1>
@@ -701,7 +717,7 @@
</listitem>
</varlistentry>
- <varlistentry id="opt.collect-atstart">
+ <varlistentry id="opt.collect-atstart" xreflabel="--collect-atstart">
<term>
<option><![CDATA[--collect-atstart=<yes|no> [default: yes] ]]></option>
</term>
@@ -733,13 +749,9 @@
specification of <computeroutput>--toggle-collect</computeroutput>
implicitly sets
<computeroutput>--collect-state=no</computeroutput>.</para>
- <para>Collection state can be toggled also by using a Valgrind
- Client Request in your application. For this, include
- <computeroutput>valgrind/callgrind.h</computeroutput> and specify
- the macro
- <computeroutput>CALLGRIND_TOGGLE_COLLECT</computeroutput> at the
- needed positions. This only will have any effect if run under
- supervision of the Callgrind tool.</para>
+ <para>Collection state can be toggled also by inserting the client request
+ <computeroutput><xref linkend="cr.toggle-collect"/>;</computeroutput>
+ at the needed code positions.</para>
</listitem>
</varlistentry>
@@ -912,4 +924,94 @@
</sect1>
+<sect1 id="cl-manual.clientrequests" xreflabel="Client request reference">
+<title>Callgrind specific client requests</title>
+
+<para>In Valgrind terminology, a client request is a C macro which
+can be inserted into your code to request specific functionality when
+run under Valgrind. For this, special instruction patterns resulting
+in NOPs are used, but which can be detected by Valgrind.</para>
+
+<para>Callgrind provides the following specific client requests.
+To use them, add the line
+<screen><![CDATA[#include <valgrind/callgrind.h>]]></screen>
+into your code for the macro definitions.
+.</para>
+
+<variablelist id="cl.clientrequests.list">
+
+ <varlistentry id="cr.dump-stats" xreflabel="CALLGRIND_DUMP_STATS">
+ <term>
+ <computeroutput>CALLGRIND_DUMP_STATS</computeroutput>
+ </term>
+ <listitem>
+ <para>Force generation of a profile dump at specified position
+ in code, for the current thread only. Written counters will be reset
+ to zero.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="cr.dump-stats-at" xreflabel="CALLGRIND_DUMP_STATS_AT">
+ <term>
+ <computeroutput>CALLGRIND_DUMP_STATS_AT(string)</computeroutput>
+ </term>
+ <listitem>
+ <para>Same as CALLGRIND_DUMP_STATS, but allows to specify a string
+ to be able to distinguish profile dumps.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="cr.zero-stats" xreflabel="CALLGRIND_ZERO_STATS">
+ <term>
+ <computeroutput>CALLGRIND_ZERO_STATS</computeroutput>
+ </term>
+ <listitem>
+ <para>Reset the profile counters for the current thread to zero.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="cr.toggle-collect" xreflabel="CALLGRIND_TOGGLE_COLLECT">
+ <term>
+ <computeroutput>CALLGRIND_TOGGLE_COLLECT</computeroutput>
+ </term>
+ <listitem>
+ <para>Toggle the collection state. This allows to ignore events
+ with regard to profile counters. See also options
+ <xref linkend="opt.collect-atstart"/> and
+ <xref linkend="opt.toggle-collect"/>.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="cr.start-instr" xreflabel="CALLGRIND_START_INSTRUMENTATION">
+ <term>
+ <computeroutput>CALLGRIND_START_INSTRUMENTATION</computeroutput>
+ </term>
+ <listitem>
+ <para>Start full Callgrind instrumentation if not already switched on.
+ When cache simulation is done, this will flush the simulated cache
+ and lead to an artifical cache warmup phase afterwards with
+ cache misses which would not have happened in reality.
+ See also option <xref linkend="opt.instr-atstart"/>.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="cr.stop-instr" xreflabel="CALLGRIND_STOP_INSTRUMENTATION">
+ <term>
+ <computeroutput>CALLGRIND_STOP_INSTRUMENTATION</computeroutput>
+ </term>
+ <listitem>
+ <para>Stop full Callgrind instrumentation if not already switched off.
+ This flushes Valgrinds translation cache, and does no additional
+ instrumentation afterwards: it effectivly will run at the same
+ speed as the "none" tool, ie. at minimal slowdown. Use this to
+ speed up the Callgrind run for uninteresting code parts. Use
+ <xref linkend="cr.start-instr"/> to switch on instrumentation again.
+ See also option <xref linkend="opt.instr-atstart"/>.</para>
+ </listitem>
+ </varlistentry>
+
+</variablelist>
+
+</sect1>
+
</chapter>
|
|
From: <sv...@va...> - 2008-10-24 18:50:06
|
Author: weidendo
Date: 2008-10-24 19:50:00 +0100 (Fri, 24 Oct 2008)
New Revision: 8704
Log:
Fix for bug 166581: use correct output file name after PID change
This is a little tricky because
* we want to check directly at startup whether the output file
can be written, thus the file name is set at beginning.
* a fork changes the PID in the child, and thus (potentially) the
output file name has to be updated. This best is directly before
generating the profile dump.
* the child after fork needs to be controllable via callgrind_control.
The setup of the control interface needs the new file name, too.
The fix is to allow multiple calls of CLG(init_dumps), everytime the
output file name is needed.
Modified:
trunk/callgrind/dump.c
Modified: trunk/callgrind/dump.c
===================================================================
--- trunk/callgrind/dump.c 2008-10-23 22:16:41 UTC (rev 8703)
+++ trunk/callgrind/dump.c 2008-10-24 18:50:00 UTC (rev 8704)
@@ -64,13 +64,13 @@
Char* CLG_(get_out_file)()
{
- CLG_ASSERT(dumps_initialized);
+ CLG_(init_dumps)();
return out_file;
}
Char* CLG_(get_out_directory)()
{
- CLG_ASSERT(dumps_initialized);
+ CLG_(init_dumps)();
return out_directory;
}
@@ -1616,6 +1616,8 @@
CLG_DEBUG(2, "+ dump_profile(Trigger '%s')\n",
trigger ? trigger : (Char*)"Prg.Term.");
+ CLG_(init_dumps)();
+
if (VG_(clo_verbosity) > 1)
VG_(message)(Vg_DebugMsg, "Start dumping at BB %llu (%s)...",
CLG_(stat).bb_executions,
@@ -1673,15 +1675,35 @@
* <out_file> always starts with a full absolute path.
* If the output format string represents a relative path, the current
* working directory at program start is used.
+ *
+ * This function has to be called every time a profile dump is generated
+ * to be able to react on PID changes.
*/
void CLG_(init_dumps)()
{
Int lastSlash, i;
SysRes res;
+ static int thisPID = 0;
+ int currentPID = VG_(getpid)();
+ if (currentPID == thisPID) {
+ /* already initialized, and no PID change */
+ CLG_ASSERT(out_file != 0);
+ return;
+ }
+ thisPID = currentPID;
+
if (!CLG_(clo).out_format)
CLG_(clo).out_format = DEFAULT_OUTFORMAT;
+ /* If a file name was already set, clean up before */
+ if (out_file) {
+ VG_(free)(out_file);
+ VG_(free)(out_directory);
+ VG_(free)(filename);
+ out_counter = 0;
+ }
+
// Setup output filename.
out_file =
VG_(expand_file_name)("--callgrind-out-file", CLG_(clo).out_format);
@@ -1721,7 +1743,8 @@
}
if (!res.isError) VG_(close)( (Int)res.res );
- init_cmdbuf();
+ if (!dumps_initialized)
+ init_cmdbuf();
dumps_initialized = True;
}
|
|
From: Tom H. <th...@cy...> - 2008-10-24 03:27:46
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2008-10-24 03:15:02 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 == 367 tests, 81 stderr failures, 2 stdout failures, 29 post failures == 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/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) helgrind/tests/hg01_all_ok (stderr) helgrind/tests/hg02_deadlock (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/hg06_readshared (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc02_simple_tls (stderr) helgrind/tests/tc03_re_excl (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc07_hbl1 (stderr) helgrind/tests/tc08_hbl2 (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc11_XCHG (stderr) helgrind/tests/tc12_rwl_trivial (stderr) helgrind/tests/tc14_laog_dinphils (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) helgrind/tests/tc24_nonzero_sem (stderr) massif/tests/alloc-fns-A (post) massif/tests/alloc-fns-B (post) massif/tests/basic (post) massif/tests/basic2 (post) massif/tests/big-alloc (post) massif/tests/culling1 (stderr) massif/tests/culling2 (stderr) massif/tests/custom_alloc (post) massif/tests/deep-A (post) massif/tests/deep-B (stderr) massif/tests/deep-B (post) massif/tests/deep-C (stderr) massif/tests/deep-C (post) massif/tests/deep-D (post) massif/tests/ignoring (post) massif/tests/insig (post) massif/tests/long-names (post) massif/tests/long-time (post) massif/tests/new-cpp (post) massif/tests/null (post) massif/tests/one (post) massif/tests/overloaded-new (post) massif/tests/peak (post) massif/tests/peak2 (stderr) massif/tests/peak2 (post) massif/tests/realloc (stderr) massif/tests/realloc (post) massif/tests/thresholds_0_0 (post) massif/tests/thresholds_0_10 (post) massif/tests/thresholds_10_0 (post) massif/tests/thresholds_10_10 (post) massif/tests/thresholds_5_0 (post) massif/tests/thresholds_5_10 (post) massif/tests/zero1 (post) massif/tests/zero2 (post) memcheck/tests/file_locking (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/long_namespace_xml (stderr) memcheck/tests/malloc_free_fill (stderr) memcheck/tests/origin1-yes (stderr) memcheck/tests/origin4-many (stderr) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_changes (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/x86/bug152022 (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/xor-undef-x86 (stderr) memcheck/tests/xml1 (stderr) none/tests/blockfault (stderr) none/tests/cmdline2 (stdout) none/tests/mremap2 (stdout) none/tests/shell (stderr) none/tests/shell_valid1 (stderr) none/tests/shell_valid2 (stderr) none/tests/shell_valid3 (stderr) |
|
From: Tom H. <th...@cy...> - 2008-10-24 03:10:45
|
Nightly build on lloyd ( x86_64, Fedora 7 ) started at 2008-10-24 03:05:09 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 == 461 tests, 12 stderr failures, 3 stdout failures, 0 post failures == exp-ptrcheck/tests/base (stderr) exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc22_exit_w_lock (stderr) memcheck/tests/file_locking (stderr) memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/scalar (stderr) none/tests/blockfault (stderr) none/tests/cmdline2 (stdout) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2008-10-24 02:47:38
|
Nightly build on trojan ( x86_64, Fedora Core 6 ) started at 2008-10-24 03:25:05 BST 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 == 465 tests, 14 stderr failures, 5 stdout failures, 0 post failures == drd/tests/pth_inconsistent_cond_wait (stderr) exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) memcheck/tests/file_locking (stderr) memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/bug133694 (stdout) memcheck/tests/x86/bug133694 (stderr) memcheck/tests/x86/scalar (stderr) none/tests/blockfault (stderr) none/tests/cmdline1 (stdout) none/tests/cmdline2 (stdout) none/tests/mremap2 (stdout) ================================================= == 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 == 465 tests, 14 stderr failures, 5 stdout failures, 0 post failures == exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) memcheck/tests/file_locking (stderr) memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/bug133694 (stdout) memcheck/tests/x86/bug133694 (stderr) memcheck/tests/x86/scalar (stderr) none/tests/blockfault (stderr) none/tests/cmdline1 (stdout) none/tests/cmdline2 (stdout) none/tests/mremap2 (stdout) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Fri Oct 24 03:36:17 2008 --- new.short Fri Oct 24 03:47:25 2008 *************** *** 9,10 **** --- 9,11 ---- == 465 tests, 14 stderr failures, 5 stdout failures, 0 post failures == + drd/tests/pth_inconsistent_cond_wait (stderr) exp-ptrcheck/tests/ccc (stderr) *************** *** 13,15 **** exp-ptrcheck/tests/pth_specific (stderr) - helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc20_verifywrap (stderr) --- 14,15 ---- |
|
From: Tom H. <th...@cy...> - 2008-10-24 02:27:48
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2008-10-24 03:00:02 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 == 467 tests, 34 stderr failures, 4 stdout failures, 0 post failures == drd/tests/pth_cancel_locked (stderr) exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/hackedbz2 (stderr) helgrind/tests/hg01_all_ok (stderr) helgrind/tests/hg02_deadlock (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc14_laog_dinphils (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) memcheck/tests/file_locking (stderr) memcheck/tests/malloc_free_fill (stderr) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/varinfo6 (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/amd64/insn_ssse3 (stdout) none/tests/amd64/insn_ssse3 (stderr) none/tests/amd64/ssse3_misaligned (stderr) none/tests/blockfault (stderr) none/tests/cmdline2 (stdout) none/tests/fdleak_fcntl (stderr) none/tests/mremap2 (stdout) none/tests/x86/insn_ssse3 (stdout) none/tests/x86/insn_ssse3 (stderr) none/tests/x86/ssse3_misaligned (stderr) |
|
From: <sv...@va...> - 2008-10-23 22:16:46
|
Author: sewardj
Date: 2008-10-23 23:16:41 +0100 (Thu, 23 Oct 2008)
New Revision: 8703
Log:
Remove old text-mode only version of the documentation.
Removed:
trunk/exp-ptrcheck/README.ABOUT.PTRCHECK.txt
Modified:
trunk/exp-ptrcheck/Makefile.am
Modified: trunk/exp-ptrcheck/Makefile.am
===================================================================
--- trunk/exp-ptrcheck/Makefile.am 2008-10-23 13:15:23 UTC (rev 8702)
+++ trunk/exp-ptrcheck/Makefile.am 2008-10-23 22:16:41 UTC (rev 8703)
@@ -126,4 +126,4 @@
noinst_HEADERS = h_main.h sg_main.h pc_common.h
-EXTRA_DIST = README.ABOUT.PTRCHECK.txt
+EXTRA_DIST =
Deleted: trunk/exp-ptrcheck/README.ABOUT.PTRCHECK.txt
===================================================================
--- trunk/exp-ptrcheck/README.ABOUT.PTRCHECK.txt 2008-10-23 13:15:23 UTC (rev 8702)
+++ trunk/exp-ptrcheck/README.ABOUT.PTRCHECK.txt 2008-10-23 22:16:41 UTC (rev 8703)
@@ -1,359 +0,0 @@
-
-0. CONTENTS
-~~~~~~~~~~~
-
-This document introduces Ptrcheck, a new, experimental Valgrind tool.
-It contains the following sections:
-
- 1. INTRODUCING PTRCHECK
- 2. HOW TO RUN IT
- 3. HOW IT WORKS: HEAP CHECKING
- 4. HOW IT WORKS: STACK & GLOBAL CHECKING
- 5. COMPARISON WITH MEMCHECK
- 6. LIMITATIONS
- 7. STILL TO DO -- User visible things
- 8. STILL TO DO -- Implementation tidying
-
-
-
-1. INTRODUCING PTRCHECK
-~~~~~~~~~~~~~~~~~~~~~~~
-
-Ptrcheck is a Valgrind tool for finding overruns of heap, stack and
-global arrays. Its functionality overlaps somewhat with Memcheck's,
-but it is able to catch invalid accesses in a number of cases that
-Memcheck would miss. A detailed comparison against Memcheck is
-presented below.
-
-Ptrcheck is composed of two almost completely independent tools that
-have been glued together. One part, in h_main.[ch], checks accesses
-through heap-derived pointers. The other part, in sg_main.[ch],
-checks accesses to stack and global arrays. The remaining files
-pc_{common,main}.[ch], provide common error-management and
-coordination functions, so as to make it appear as a single tool.
-
-The heap-check part is an extensively-hacked (largely rewritten)
-version of the experimental "Annelid" tool developed and described by
-Nicholas Nethercote and Jeremy Fitzhardinge. The stack- and global-
-check part uses a heuristic approach derived from an observation about
-the likely forms of stack and global array accesses, and, as far as is
-known, is entirely novel.
-
-
-
-2. HOW TO RUN IT
-~~~~~~~~~~~~~~~~
-
-valgrind --tool=exp-ptrcheck [myprog] [args for myprog]
-
-There are no Ptrcheck specific flags at present.
-
-
-
-3. HOW IT WORKS: HEAP CHECKING
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Ptrcheck can check for invalid uses of heap pointers, including out of
-range accesses and accesses to freed memory. The mechanism is however
-completely different from Memcheck's, and the checking is more
-powerful.
-
-For each pointer in the program, Ptrcheck keeps track of which heap
-block (if any) it was derived from. Then, when an access is made
-through that pointer, Ptrcheck compares the access address with the
-bounds of the associated block, and reports an error if the address is
-out of bounds, or if the block has been freed.
-
-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 block results
-in a pointer to the same block.
-
-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.
-
-
-
-4. HOW IT WORKS: STACK & GLOBAL CHECKING
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-When a source file is compiled with "-g", the compiler attaches Dwarf3
-debugging information which describes the location of all stack and
-global arrays in the file.
-
-Checking of accesses to such arrays would then be relatively simple,
-if the compiler could also tell us which array (if any) each memory
-referencing instruction was supposed to access. Unfortunately 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
-
- if a memory referencing instruction accesses inside a stack or
- global array once, then it is highly likely to always access that
- same array
-
-To see how this might be useful, consider the following buggy
-fragment:
-
- { int i, a[10]; // both are auto vars
- for (i = 0; i <= 10; i++)
- a[i] = 42;
- }
-
-At run time we will know the precise address of a[] on the stack, and
-so we can observer that the first store resulting from "a[i] = 42"
-writes a[], and we will (correctly) assume that that instruction is
-intended always to access a[]. Then, on the 11th iteration, it
-accesses somewhere else, possibly a different local, possibly an
-un-accounted for area of the stack (eg, spill slot), so Ptrcheck
-reports an error.
-
-There is an important caveat.
-
-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.
-
-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.
-
-
-
-5. COMPARISON WITH MEMCHECK
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Memcheck does not do any access checks for stack or global arrays, so
-the presence of those in Ptrcheck is a straight win. (But see
-LIMITATIONS below).
-
-Memcheck and Ptrcheck use different approaches for checking heap
-accesses. Memcheck maintains bitmaps telling it which areas of memory
-are accessible and which are not. If a memory access falls in an
-unaccessible area, it reports an error. By marking the 16 bytes
-before and after an allocated block unaccessible, Memcheck is able to
-detect small over- and underruns of the block. Similarly, by marking
-freed memory as unaccessible, Memcheck can detect all accesses to
-freed memory.
-
-Memcheck's approach is simple. But it's also weak. It can't catch
-block overruns beyond 16 bytes. And, more generally, because it
-focusses only on the question "is the target address accessible", it
-fails to detect invalid accesses which just happen to fall within some
-other valid area. This is not improbable, especially in crowded areas
-of the process' address space.
-
-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
-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 bounds.
-
-Consequently Ptrcheck can detect any out of bounds access through a
-heap-derived pointer, no matter how far from the original block it is.
-
-A second advantage is that Ptrcheck is better at detecting accesses to
-blocks freed very far in the past. Memcheck can detect these too, but
-only for blocks freed relatively recently. To detect accesses to a
-freed block, Memcheck must make it inaccessible, hence requiring a
-space overhead proportional to the size of the block. If the blocks
-are large, Memcheck will have to make them available for re-allocation
-relatively quickly, thereby losing the ability to detect invalid
-accesses to them.
-
-By contrast, Ptrcheck has a constant per-block space requirement of
-four machine words, for detection of accesses to freed blocks. A
-freed block can be reallocated immediately, yet Ptrcheck can still
-detect all invalid accesses through any pointers derived from the old
-allocation, providing only that the four-word descriptor for the old
-allocation is stored. For example, on a 64-bit machine, to detect
-accesses in any of the most recently freed 10 million blocks, Ptrcheck
-will require only 320MB of extra storage. Achieveing the same level
-of detection with Memcheck is close to impossible and would likely
-involve several gigabytes of extra storage.
-
-In defense of Memcheck ...
-
-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 September
-2008.
-
-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.
-
-
-
-6. LIMITATIONS
-~~~~~~~~~~~~~~
-
-This is an experimental tool, which relies rather too heavily on some
-not-as-robust-as-I-would-like assumptions on the behaviour of correct
-programs. There are a number of limitations which you should be aware
-of.
-
-* Heap checks: Ptrcheck can occasionally lose track of, or become
- confused about, which heap block a given pointer has been derived
- from. This can cause it to falsely report errors, or to miss some
- errors. This is not believed to be a serious problem.
-
-* Heap checks: Ptrcheck only tracks pointers that are stored properly
- aligned in memory. If a pointer is stored at a misaligned address,
- and then later read again, Ptrcheck will lose track of what it
- points at. Similar problem if a pointer is split into pieces and
- later reconsitituted.
-
-* 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.
-
-* Stack checks: It follows from the description above (HOW IT WORKS:
- STACK & GLOBAL CHECKING) 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.
-
-* Stack checks: Similarly, and more serious, it is clearly possible to
- write legitimate pieces of code which break the basic assumption
- upon which the stack/global checking rests. For example:
-
- { int a[10], b[10], *p, i;
- for (i = 0; i < 10; i++) {
- p = /* arbitrary condition */ ? &a[i] : &b[i];
- *p = 42;
- }
- }
-
- In this case the store sometimes accesses a[] and sometimes b[], but
- in no cases is the addressed array overrun. Nevertheless the change
- in target will cause an error to be reported.
-
- It is hard to see how to get around this problem. The only
- mitigating factor is that such constructions appear very rare, at
- least judging from the results using the tool so far. Such a
- construction appears only once in the Valgrind sources (running
- Valgrind on Valgrind) and perhaps two or three times for a start and
- exit of Firefox. The best that can be done is to suppress the
- errors.
-
-* Performance: the stack/global checks require reading all of the
- Dwarf3 type and variable information on the executable and its
- shared objects. This is computationally expensive and makes startup
- quite slow. You can expect debuginfo reading time to be in the
- region of a minute for an OpenOffice sized application, on a 2.4 GHz
- Core 2 machine. Reading this information also requires a lot of
- memory. To make it viable, Ptrcheck goes to considerable trouble to
- compress the in-memory representation of the Dwarf3 data, which is
- why the process of reading it appears slow.
-
-* Performance: Ptrcheck runs slower than Memcheck. This is partly due
- to a lack of tuning, but partly due to algorithmic difficulties.
- The heap-check side is potentially quite fast. The stack and global
- checks can sometimes require a number of range checks per memory
- access, and these are difficult to short-circuit (despite
- considerable efforts having been made).
-
-* 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 attached.
-
- Stack/global checking is much more fragile. If a shared object does
- not have debug information attached, then Ptrcheck will not be able
- to determine the bounds of any stack or global arrays defined within
- that shared object, and so will not be able to check accesses to
- them. This is true even when those arrays are accessed from some
- other shared object which was compiled with debug info.
-
- At the moment Ptrcheck accepts objects lacking debuginfo without
- comment. This is dangerous as it causes Ptrcheck to silently skip
- stack & global checking for such objects. It would be better to
- print a warning in such circumstances.
-
-* Coverage: Ptrcheck checks that the areas read or written by system
- calls do not overrun heap blocks. But it doesn't currently check
- them for overruns stack and global arrays. This would be easy to
- add.
-
-* Platforms: the stack/global checks won't work properly on any
- 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
- straightforward.)
-
-* Robustness: related to the previous point. Function call/exit
- tracking for x86/amd64 is believed to work properly even in the
- presence of longjmps within the same stack (although this has not
- been tested). However, code which switches stacks is likely to
- cause breakage/chaos.
-
-
-
-7. STILL TO DO -- User visible things
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-* Extend system call checking to work on stack and global arrays
-
-* Print a warning if a shared object does not have debug info attached
-
-
-
-8. STILL TO DO -- Implementation tidying
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Items marked CRITICAL are considered important for correctness:
-non-fixage of them is liable to lead to crashes or assertion failures
-in real use.
-
-* h_main.c: make N_FREED_SEGS command-line configurable
-
-* Maybe add command line options to enable only heap checking, or only
- stack/global checking
-
-* sg_main.c: Improve the performance of the stack / global checks by
- doing some up-front filtering to ignore references in areas which
- "obviously" can't be stack or globals. This will require
- using information that m_aspacemgr knows about the address space
- layout.
-
-* h_main.c: get rid of the last_seg_added hack; add suitable plumbing
- to the core/tool interface to do this cleanly
-
-* h_main.c: move vast amounts of arch-dependent uglyness
- (get_IntRegInfo et al) to its own source file, a la mc_machine.c.
-
-* h_main.c: make the lossage-check stuff work again, as a way of doing
- quality assurance on the implementation
-
-* h_main.c: schemeEw_Atom: don't generate a call to nonptr_or_unknown,
- this is really stupid, since it could be done at translation time
- instead
-
-* CRITICAL: h_main.c: h_instrument (main instrumentation fn): generate
- shadows for word-sized temps defined in the block's preamble. (Why
- does this work at all, as it stands?)
-
-* 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)
|
|
From: <sv...@va...> - 2008-10-23 13:18:21
|
Author: sewardj
Date: 2008-10-23 14:15:23 +0100 (Thu, 23 Oct 2008)
New Revision: 8702
Log:
XML-ise exp-ptrcheck's documentation.
Added:
trunk/exp-ptrcheck/docs/pc-manual.xml
Modified:
trunk/docs/xml/manual.xml
trunk/docs/xml/valgrind-manpage.xml
trunk/exp-ptrcheck/docs/Makefile.am
Modified: trunk/docs/xml/manual.xml
===================================================================
--- trunk/docs/xml/manual.xml 2008-10-23 11:13:05 UTC (rev 8701)
+++ trunk/docs/xml/manual.xml 2008-10-23 13:15:23 UTC (rev 8702)
@@ -36,6 +36,8 @@
xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="../../massif/docs/ms-manual.xml" parse="xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="../../exp-ptrcheck/docs/pc-manual.xml" parse="xml"
+ xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="../../none/docs/nl-manual.xml" parse="xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="../../lackey/docs/lk-manual.xml" parse="xml"
Modified: trunk/docs/xml/valgrind-manpage.xml
===================================================================
--- trunk/docs/xml/valgrind-manpage.xml 2008-10-23 11:13:05 UTC (rev 8701)
+++ trunk/docs/xml/valgrind-manpage.xml 2008-10-23 13:15:23 UTC (rev 8702)
@@ -250,6 +250,17 @@
+<refsect1 id="ptrcheck-options">
+<title>Ptrcheck Options</title>
+
+<xi:include href="../../exp-ptrcheck/docs/pc-manual.xml"
+ xpointer="pc.opts.list"
+ xmlns:xi="http://www.w3.org/2001/XInclude" />
+
+</refsect1>
+
+
+
<refsect1 id="lackey-options">
<title>Lackey Options</title>
Modified: trunk/exp-ptrcheck/docs/Makefile.am
===================================================================
--- trunk/exp-ptrcheck/docs/Makefile.am 2008-10-23 11:13:05 UTC (rev 8701)
+++ trunk/exp-ptrcheck/docs/Makefile.am 2008-10-23 13:15:23 UTC (rev 8702)
@@ -0,0 +1 @@
+EXTRA_DIST = pc-manual.xml
Added: trunk/exp-ptrcheck/docs/pc-manual.xml
===================================================================
--- trunk/exp-ptrcheck/docs/pc-manual.xml (rev 0)
+++ trunk/exp-ptrcheck/docs/pc-manual.xml 2008-10-23 13:15:23 UTC (rev 8702)
@@ -0,0 +1,531 @@
+<?xml version="1.0"?> <!-- -*- sgml -*- -->
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+ "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[ <!ENTITY % vg-entities SYSTEM "../../docs/xml/vg-entities.xml"> %vg-entities; ]>
+
+
+<chapter id="pc-manual"
+ xreflabel="Ptrcheck: an (experimental) pointer checking tool">
+ <title>Ptrcheck: an (experimental) pointer checking tool</title>
+
+<para>To use this tool, you must specify
+<computeroutput>--tool=exp-ptrcheck</computeroutput> on the Valgrind
+command line.</para>
+
+
+
+
+<sect1 id="pc-manual.overview" xreflabel="Overview">
+<title>Overview</title>
+
+<para>Ptrcheck is a Valgrind tool for finding overruns of heap, stack
+and global arrays. Its functionality overlaps somewhat with
+Memcheck's, but it is able to catch invalid accesses in a number of
+cases that Memcheck would miss. A detailed comparison against
+Memcheck is presented below.</para>
+
+<para>Ptrcheck is composed of two almost completely independent tools
+that have been glued together. One part,
+in <computeroutput>h_main.[ch]</computeroutput>, checks accesses
+through heap-derived pointers. The other part, in
+<computeroutput>sg_main.[ch]</computeroutput>, checks accesses to
+stack and global arrays. The remaining
+files <computeroutput>pc_{common,main}.[ch]</computeroutput>, provide
+common error-management and coordination functions, so as to make it
+appear as a single tool.</para>
+
+<para>The heap-check part is an extensively-hacked (largely rewritten)
+version of the experimental "Annelid" tool developed and described by
+Nicholas Nethercote and Jeremy Fitzhardinge. The stack- and global-
+check part uses a heuristic approach derived from an observation about
+the likely forms of stack and global array accesses, and, as far as is
+known, is entirely novel.</para>
+
+</sect1>
+
+
+
+
+<sect1 id="pc-manual.options" xreflabel="Ptrcheck Options">
+<title>Ptrcheck Options</title>
+
+<para>The following end-user options are available:</para>
+
+<!-- start of xi:include in the manpage -->
+<variablelist id="pc.opts.list">
+
+ <varlistentry id="opt.enable-sg-checks" xreflabel="--enable-sg-checks">
+ <term>
+ <option><![CDATA[--enable-sg-checks=no|yes
+ [default: yes] ]]></option>
+ </term>
+ <listitem>
+ <para>By default, Ptrcheck checks for overruns of stack, global
+ and heap arrays.
+ With <varname>--enable-sg-checks=no</varname>, the stack and
+ global array checks are omitted, and only heap checking is
+ performed. This can be useful because the stack and global
+ checks are quite expensive, so omitting them speeds Ptrcheck up
+ a lot.
+ </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>This option has the same meaning as it does for
+ Memcheck.</para>
+ <para>Controls how Ptrcheck handles word-sized, word-aligned
+ loads which partially overlap the end of heap blocks -- that is,
+ some of the bytes in the word are validly addressable, but
+ others are not. When <varname>yes</varname>, such loads do not
+ produce an address error. When <varname>no</varname> (the
+ default), loads from partially invalid addresses are treated the
+ same as loads from completely invalid addresses: an illegal heap
+ access error is issued.
+ </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>
+
+</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>
+
+
+
+
+<sect1 id="pc-manual.how-works.heap-checks"
+ xreflabel="How Ptrcheck Works: Heap Checks">
+<title>How Ptrcheck Works: Heap Checks</title>
+
+<para>Ptrcheck can check for invalid uses of heap pointers, including
+out of range accesses and accesses to freed memory. The mechanism is
+however completely different from Memcheck's, and the checking is more
+powerful.</para>
+
+<para>For each pointer in the program, Ptrcheck keeps track of which
+heap block (if any) it was derived from. Then, when an access is made
+through that pointer, Ptrcheck compares the access address with the
+bounds of the associated block, and reports an error if the address is
+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
+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>
+
+</sect1>
+
+
+
+<sect1 id="pc-manual.how-works.sg-checks"
+ xreflabel="How Ptrcheck Works: Stack and Global Checks">
+<title>How Ptrcheck Works: Stack and Global Checks</title>
+
+<para>When a source file is compiled
+with <computeroutput>-g</computeroutput>, the compiler attaches DWARF3
+debugging information which describes the location of all stack and
+global arrays in the file.</para>
+
+<para>Checking of accesses to such arrays would then be relatively
+simple, if the compiler could also tell us which array (if any) each
+memory referencing instruction was supposed to access. Unfortunately
+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>
+ 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>
+
+<para>To see how this might be useful, consider the following buggy
+fragment:</para>
+<programlisting><![CDATA[
+ { int i, a[10]; // both are auto vars
+ for (i = 0; i <= 10; i++)
+ a[i] = 42;
+ }
+]]></programlisting>
+
+<para>At run time we will know the precise address
+of <computeroutput>a[]</computeroutput> on the stack, and so we can
+observe that the first store resulting from <computeroutput>a[i] =
+42</computeroutput> writes <computeroutput>a[]</computeroutput>, and
+we will (correctly) assume that that instruction is intended always to
+access <computeroutput>a[]</computeroutput>. Then, on the 11th
+iteration, it accesses somewhere else, possibly a different local,
+possibly an un-accounted for area of the stack (eg, spill slot), so
+Ptrcheck reports an error.</para>
+
+<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>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>
+
+</sect1>
+
+
+
+
+<sect1 id="pc-manual.cmp-w-memcheck"
+ xreflabel="Comparison with Memcheck">
+<title>Comparison with Memcheck</title>
+
+<para>Memcheck does not do any access checks for stack or global arrays, so
+the presence of those in Ptrcheck is a straight win. (But see
+"Limitations" below).</para>
+
+<para>Memcheck and Ptrcheck use different approaches for checking heap
+accesses. Memcheck maintains bitmaps telling it which areas of memory
+are accessible and which are not. If a memory access falls in an
+unaccessible area, it reports an error. By marking the 16 bytes
+before and after an allocated block unaccessible, Memcheck is able to
+detect small over- and underruns of the block. Similarly, by marking
+freed memory as unaccessible, Memcheck can detect all accesses to
+freed memory.</para>
+
+<para>Memcheck's approach is simple. But it's also weak. It can't
+catch block overruns beyond 16 bytes. And, more generally, because it
+focusses only on the question "is the target address accessible", it
+fails to detect invalid accesses which just happen to fall within some
+other valid area. This is not improbable, especially in crowded areas
+of the process' address space.</para>
+
+<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
+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
+bounds.</para>
+
+<para>Consequently Ptrcheck can detect any out of bounds access
+through a heap-derived pointer, no matter how far from the original
+block it is.</para>
+
+<para>A second advantage is that Ptrcheck is better at detecting
+accesses to blocks freed very far in the past. Memcheck can detect
+these too, but only for blocks freed relatively recently. To detect
+accesses to a freed block, Memcheck must make it inaccessible, hence
+requiring a space overhead proportional to the size of the block. If
+the blocks are large, Memcheck will have to make them available for
+re-allocation relatively quickly, thereby losing the ability to detect
+invalid accesses to them.</para>
+
+<para>By contrast, Ptrcheck has a constant per-block space requirement
+of four machine words, for detection of accesses to freed blocks. A
+freed block can be reallocated immediately, yet Ptrcheck can still
+detect all invalid accesses through any pointers derived from the old
+allocation, providing only that the four-word descriptor for the old
+allocation is stored. For example, on a 64-bit machine, to detect
+accesses in any of the most recently freed 10 million blocks, Ptrcheck
+will require only 320MB of extra storage. Achieving the same level of
+detection with Memcheck is close to impossible and would likely
+involve several gigabytes of extra storage.</para>
+
+<para>In defense of Memcheck ...</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 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>
+
+
+
+
+
+<sect1 id="pc-manual.limitations"
+ xreflabel="Limitations">
+<title>Limitations</title>
+
+<para>This is an experimental tool, which relies rather too heavily on some
+not-as-robust-as-I-would-like assumptions on the behaviour of correct
+programs. There are a number of limitations which you should be aware
+of.</para>
+
+<itemizedlist>
+
+ <listitem>
+ <para>Heap checks: Ptrcheck can occasionally lose track of, or
+ become confused about, which heap block a given pointer has been
+ derived from. This can cause it to falsely report errors, or to
+ miss some errors. This is not believed to be a serious
+ problem.</para>
+ </listitem>
+
+ <listitem>
+ <para>Heap checks: Ptrcheck only tracks pointers that are stored
+ properly aligned in memory. If a pointer is stored at a misaligned
+ address, and then later read again, Ptrcheck will lose track of
+ what it points at. Similar problem if a pointer is split into
+ pieces and later reconsitituted.</para>
+ </listitem>
+
+ <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>
+ </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>
+ </listitem>
+
+ <listitem>
+ <para>Stack checks: Similarly, and more serious, it is clearly
+ possible to write legitimate pieces of code which break the basic
+ assumption upon which the stack/global checking rests. For
+ example:</para>
+
+<programlisting><![CDATA[
+ { int a[10], b[10], *p, i;
+ for (i = 0; i < 10; i++) {
+ p = /* arbitrary condition */ ? &a[i] : &b[i];
+ *p = 42;
+ }
+ }
+]]></programlisting>
+
+ <para>In this case the store sometimes
+ accesses <computeroutput>a[]</computeroutput> and
+ sometimes <computeroutput>b[]</computeroutput>, but in no cases is
+ the addressed array overrun. Nevertheless the change in target
+ will cause an error to be reported.</para>
+
+ <para>It is hard to see how to get around this problem. The only
+ mitigating factor is that such constructions appear very rare, at
+ least judging from the results using the tool so far. Such a
+ construction appears only once in the Valgrind sources (running
+ Valgrind on Valgrind) and perhaps two or three times for a start
+ and exit of Firefox. The best that can be done is to suppress the
+ errors.</para>
+ </listitem>
+
+ <listitem>
+ <para>Performance: the stack/global checks require reading all of
+ the DWARF3 type and variable information on the executable and its
+ shared objects. This is computationally expensive and makes
+ startup quite slow. You can expect debuginfo reading time to be in
+ the region of a minute for an OpenOffice sized application, on a
+ 2.4 GHz Core 2 machine. Reading this information also requires a
+ lot of memory. To make it viable, Ptrcheck goes to considerable
+ trouble to compress the in-memory representation of the DWARF3
+ data, which is why the process of reading it appears slow.</para>
+ </listitem>
+
+ <listitem>
+ <para>Performance: Ptrcheck runs slower than Memcheck. This is
+ partly due to a lack of tuning, but partly due to algorithmic
+ difficulties. The heap-check side is potentially quite fast. The
+ stack and global checks can sometimes require a number of range
+ checks per memory access, and these are difficult to short-circuit
+ (despite considerable efforts having been made).
+ </para>
+ </listitem>
+
+ <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
+ attached.</para>
+
+ <para>Stack/global checking is much more fragile. If a shared
+ object does not have debug information attached, then Ptrcheck will
+ not be able to determine the bounds of any stack or global arrays
+ defined within that shared object, and so will not be able to check
+ accesses to them. This is true even when those arrays are accessed
+ from some other shared object which was compiled with debug
+ info.</para>
+
+ <para>At the moment Ptrcheck accepts objects lacking debuginfo
+ without comment. This is dangerous as it causes Ptrcheck to
+ silently skip stack and global checking for such objects. It would
+ be better to print a warning in such circumstances.</para>
+ </listitem>
+
+ <listitem>
+ <para>Coverage: Ptrcheck checks that the areas read or written by
+ system calls do not overrun heap blocks. But it doesn't currently
+ check them for overruns stack and global arrays. This would be
+ easy to add.</para>
+ </listitem>
+
+ <listitem>
+ <para>Platforms: the stack/global checks won't work properly on any
+ 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
+ straightforward.)</para>
+ </listitem>
+
+ <listitem>
+ <para>Robustness: related to the previous point. Function
+ call/exit tracking for x86/amd64 is believed to work properly even
+ in the presence of longjmps within the same stack (although this
+ has not been tested). However, code which switches stacks is
+ likely to cause breakage/chaos.</para>
+ </listitem>
+</itemizedlist>
+
+</sect1>
+
+
+
+
+
+<sect1 id="pc-manual.todo-user-visible"
+ xreflabel="Still To Do: User Visible Functionality">
+<title>Still To Do: User Visible Functionality</title>
+
+<itemizedlist>
+
+ <listitem>
+ <para>Extend system call checking to work on stack and global arrays.</para>
+ </listitem>
+
+ <listitem>
+ <para>Print a warning if a shared object does not have debug info
+ attached, or if, for whatever reason, debug info could not be
+ found, or read.</para>
+ </listitem>
+
+</itemizedlist>
+
+</sect1>
+
+
+
+
+<sect1 id="pc-manual.todo-implementation"
+ xreflabel="Still To Do: Implementation Tidying">
+<title>Still To Do: Implementation Tidying</title>
+
+<para>Items marked CRITICAL are considered important for correctness:
+non-fixage of them is liable to lead to crashes or assertion failures
+in real use.</para>
+
+<itemizedlist>
+
+ <listitem>
+ <para>h_main.c: make N_FREED_SEGS command-line configurable.</para>
+ </listitem>
+
+ <listitem>
+ <para> sg_main.c: Improve the performance of the stack / global
+ checks by doing some up-front filtering to ignore references in
+ areas which "obviously" can't be stack or globals. This will
+ require using information that m_aspacemgr knows about the address
+ space layout.</para>
+ </listitem>
+
+ <listitem>
+ <para>h_main.c: get rid of the last_seg_added hack; add suitable
+ plumbing to the core/tool interface to do this cleanly.</para>
+ </listitem>
+
+ <listitem>
+ <para>h_main.c: move vast amounts of arch-dependent uglyness
+ (get_IntRegInfo et al) to its own source file, a la
+ mc_machine.c.</para>
+ </listitem>
+
+ <listitem>
+ <para>h_main.c: make the lossage-check stuff work again, as a way
+ of doing quality assurance on the implementation.</para>
+ </listitem>
+
+ <listitem>
+ <para>h_main.c: schemeEw_Atom: don't generate a call to
+ nonptr_or_unknown, this is really stupid, since it could be done at
+ translation time instead.</para>
+ </listitem>
+
+ <listitem>
+ <para>CRITICAL: h_main.c: h_instrument (main instrumentation fn):
+ generate shadows for word-sized temps defined in the block's
+ preamble. (Why does this work at all, as it stands?)</para>
+ </listitem>
+
+ <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>
+ </listitem>
+
+</itemizedlist>
+
+</sect1>
+
+
+
+</chapter>
|
|
From: <sv...@va...> - 2008-10-23 11:19:09
|
Author: sewardj
Date: 2008-10-23 12:13:05 +0100 (Thu, 23 Oct 2008)
New Revision: 8701
Log:
get_Form_contents: handle DW_FORM_block2.
Modified:
trunk/coregrind/m_debuginfo/readdwarf3.c
Modified: trunk/coregrind/m_debuginfo/readdwarf3.c
===================================================================
--- trunk/coregrind/m_debuginfo/readdwarf3.c 2008-10-23 10:54:40 UTC (rev 8700)
+++ trunk/coregrind/m_debuginfo/readdwarf3.c 2008-10-23 11:13:05 UTC (rev 8701)
@@ -1129,6 +1129,19 @@
*ctsMemSzB = (UWord)u64;
break;
}
+ case DW_FORM_block2: {
+ ULong u64b;
+ ULong u64 = (ULong)get_UShort(c);
+ UChar* block = get_address_of_Cursor(c);
+ TRACE_D3("%llu byte block: ", u64);
+ for (u64b = u64; u64b > 0; u64b--) {
+ UChar u8 = get_UChar(c);
+ TRACE_D3("%x ", (UInt)u8);
+ }
+ *cts = (ULong)(UWord)block;
+ *ctsMemSzB = (UWord)u64;
+ break;
+ }
default:
VG_(printf)("get_Form_contents: unhandled %d (%s)\n",
form, ML_(pp_DW_FORM)(form));
|
|
From: <sv...@va...> - 2008-10-23 11:00:43
|
Author: sewardj
Date: 2008-10-23 11:54:40 +0100 (Thu, 23 Oct 2008)
New Revision: 8700
Log:
Tolerate apparently broken Dwarf3 generated by gcc (GCC) 4.4.0
20081017 (experimental): accept DW_TAG_enumerator with only a
DW_AT_name but no DW_AT_const_value. This is in violation of the
Dwarf3 standard.
Modified:
trunk/coregrind/m_debuginfo/priv_tytypes.h
trunk/coregrind/m_debuginfo/readdwarf3.c
trunk/coregrind/m_debuginfo/tytypes.c
Modified: trunk/coregrind/m_debuginfo/priv_tytypes.h
===================================================================
--- trunk/coregrind/m_debuginfo/priv_tytypes.h 2008-10-23 10:16:02 UTC (rev 8699)
+++ trunk/coregrind/m_debuginfo/priv_tytypes.h 2008-10-23 10:54:40 UTC (rev 8700)
@@ -72,6 +72,7 @@
} UNKNOWN;
struct {
UChar* name; /* in mallocville */
+ Bool valueKnown; /* atoms w/ unknown value are possible */
Long value;
} Atom;
struct {
Modified: trunk/coregrind/m_debuginfo/readdwarf3.c
===================================================================
--- trunk/coregrind/m_debuginfo/readdwarf3.c 2008-10-23 10:16:02 UTC (rev 8699)
+++ trunk/coregrind/m_debuginfo/readdwarf3.c 2008-10-23 10:54:40 UTC (rev 8700)
@@ -2226,8 +2226,37 @@
goto acquire_Type;
}
+ /* gcc (GCC) 4.4.0 20081017 (experimental) occasionally produces
+ DW_TAG_enumerator with only a DW_AT_name but no
+ DW_AT_const_value. This is in violation of the Dwarf3 standard,
+ and appears to be a new "feature" of gcc - versions 4.3.x and
+ earlier do not appear to do this. So accept DW_TAG_enumerator
+ which only have a name but no value. An example:
+
+ <1><180>: Abbrev Number: 6 (DW_TAG_enumeration_type)
+ <181> DW_AT_name : (indirect string, offset: 0xda70):
+ QtMsgType
+ <185> DW_AT_byte_size : 4
+ <186> DW_AT_decl_file : 14
+ <187> DW_AT_decl_line : 1480
+ <189> DW_AT_sibling : <0x1a7>
+ <2><18d>: Abbrev Number: 7 (DW_TAG_enumerator)
+ <18e> DW_AT_name : (indirect string, offset: 0x9e18):
+ QtDebugMsg
+ <2><192>: Abbrev Number: 7 (DW_TAG_enumerator)
+ <193> DW_AT_name : (indirect string, offset: 0x1505f):
+ QtWarningMsg
+ <2><197>: Abbrev Number: 7 (DW_TAG_enumerator)
+ <198> DW_AT_name : (indirect string, offset: 0x16f4a):
+ QtCriticalMsg
+ <2><19c>: Abbrev Number: 7 (DW_TAG_enumerator)
+ <19d> DW_AT_name : (indirect string, offset: 0x156dd):
+ QtFatalMsg
+ <2><1a1>: Abbrev Number: 7 (DW_TAG_enumerator)
+ <1a2> DW_AT_name : (indirect string, offset: 0x13660):
+ QtSystemMsg
+ */
if (dtag == DW_TAG_enumerator) {
- Bool have_value = False;
VG_(memset)( &atomE, 0, sizeof(atomE) );
atomE.cuOff = posn;
atomE.tag = Te_Atom;
@@ -2244,11 +2273,11 @@
}
if (attr == DW_AT_const_value && ctsSzB > 0) {
atomE.Te.Atom.value = cts;
- have_value = True;
+ atomE.Te.Atom.valueKnown = True;
}
}
/* Do we have something that looks sane? */
- if ((!have_value) || atomE.Te.Atom.name == NULL)
+ if (atomE.Te.Atom.name == NULL)
goto bad_DIE;
/* Do we have a plausible parent? */
if (typestack_is_empty(parser)) goto bad_DIE;
Modified: trunk/coregrind/m_debuginfo/tytypes.c
===================================================================
--- trunk/coregrind/m_debuginfo/tytypes.c 2008-10-23 10:16:02 UTC (rev 8699)
+++ trunk/coregrind/m_debuginfo/tytypes.c 2008-10-23 10:54:40 UTC (rev 8700)
@@ -92,7 +92,8 @@
VG_(printf)("UNKNOWN");
break;
case Te_Atom:
- VG_(printf)("Te_Atom(%lld,\"%s\")",
+ VG_(printf)("Te_Atom(%s%lld,\"%s\")",
+ te->Te.Atom.valueKnown ? "" : "unknown:",
te->Te.Atom.value, te->Te.Atom.name);
break;
case Te_Field:
@@ -459,6 +460,8 @@
r = UWord__cmp(te1->Te.INDIR.indR, te2->Te.INDIR.indR);
return r;
case Te_Atom:
+ r = Bool__cmp(te1->Te.Atom.valueKnown, te2->Te.Atom.valueKnown);
+ if (r != 0) return r;
r = Long__cmp(te1->Te.Atom.value, te2->Te.Atom.value);
if (r != 0) return r;
r = Asciiz__cmp(te1->Te.Atom.name, te2->Te.Atom.name);
|
|
From: <sv...@va...> - 2008-10-23 10:20:25
|
Author: sewardj
Date: 2008-10-23 11:16:02 +0100 (Thu, 23 Oct 2008)
New Revision: 8699
Log:
Add further zlib suppressions.
Modified:
trunk/xfree-4.supp
Modified: trunk/xfree-4.supp
===================================================================
--- trunk/xfree-4.supp 2008-10-23 10:15:37 UTC (rev 8698)
+++ trunk/xfree-4.supp 2008-10-23 10:16:02 UTC (rev 8699)
@@ -3,6 +3,10 @@
# Errors to suppress by default with XFree86 4.1.0)
+# *** And a bunch of other stuff which is completely unrelated
+# to X. The default suppressions are a bit of a mess and could do
+# with a good tidying up.
+
# Format of this file is:
# {
# name_of_suppression
@@ -314,6 +318,12 @@
obj:/*lib*/libz.so.1.2.*
fun:deflate
}
+{
+ zlib-1.2.x trickyness (1b): See http://www.zlib.net/zlib_faq.html#faq36
+ Memcheck:Cond
+ obj:/*lib*/libz.so.1.2.*
+ fun:deflate
+}
{
zlib-1.2.x trickyness (2a): See http://www.zlib.net/zlib_faq.html#faq36
@@ -322,6 +332,12 @@
obj:/*lib*/libz.so.1.2.*
fun:deflate
}
+{
+ zlib-1.2.x trickyness (2b): See http://www.zlib.net/zlib_faq.html#faq36
+ Memcheck:Value8
+ obj:/*lib*/libz.so.1.2.*
+ fun:deflate
+}
{
zlib-1.2.x trickyness (3a): See http://www.zlib.net/zlib_faq.html#faq36
@@ -330,6 +346,12 @@
obj:/*lib*/libz.so.1.2.*
fun:deflate
}
+{
+ zlib-1.2.x trickyness (3b): See http://www.zlib.net/zlib_faq.html#faq36
+ Memcheck:Value4
+ obj:/*lib*/libz.so.1.2.*
+ fun:deflate
+}
##----------------------------------------------------------------------##
|
|
From: <sv...@va...> - 2008-10-23 10:19:59
|
Author: sewardj
Date: 2008-10-23 11:15:37 +0100 (Thu, 23 Oct 2008)
New Revision: 8698
Log:
Read suppression files in 256 byte chunks, not 64 byte chunks.
Modified:
trunk/coregrind/m_errormgr.c
Modified: trunk/coregrind/m_errormgr.c
===================================================================
--- trunk/coregrind/m_errormgr.c 2008-10-23 09:46:59 UTC (rev 8697)
+++ trunk/coregrind/m_errormgr.c 2008-10-23 10:15:37 UTC (rev 8698)
@@ -848,21 +848,21 @@
static Int get_char ( Int fd, Char* out_buf )
{
Int r;
- static Char buf[64];
+ static Char buf[256];
static Int buf_size = 0;
static Int buf_used = 0;
- vg_assert(buf_size >= 0 && buf_size <= 64);
+ vg_assert(buf_size >= 0 && buf_size <= 256);
vg_assert(buf_used >= 0 && buf_used <= buf_size);
if (buf_used == buf_size) {
- r = VG_(read)(fd, buf, 64);
+ r = VG_(read)(fd, buf, 256);
if (r < 0) return r; /* read failed */
- vg_assert(r >= 0 && r <= 64);
+ vg_assert(r >= 0 && r <= 256);
buf_size = r;
buf_used = 0;
}
if (buf_size == 0)
return 0; /* eof */
- vg_assert(buf_size >= 0 && buf_size <= 64);
+ vg_assert(buf_size >= 0 && buf_size <= 256);
vg_assert(buf_used >= 0 && buf_used < buf_size);
*out_buf = buf[buf_used];
buf_used++;
|
|
From: <sv...@va...> - 2008-10-23 09:53:50
|
Author: sewardj
Date: 2008-10-23 10:47:47 +0100 (Thu, 23 Oct 2008)
New Revision: 1866
Log:
Stop gcc-4.4.0 (snapshot) complaining about strict-aliasing violations.
Modified:
trunk/priv/guest-generic/bb_to_IR.c
Modified: trunk/priv/guest-generic/bb_to_IR.c
===================================================================
--- trunk/priv/guest-generic/bb_to_IR.c 2008-10-11 10:07:55 UTC (rev 1865)
+++ trunk/priv/guest-generic/bb_to_IR.c 2008-10-23 09:47:47 UTC (rev 1866)
@@ -376,9 +376,12 @@
irsb->stmts[selfcheck_idx+3]
= IRStmt_Put( offB_TILEN, IRExpr_RdTmp(tilen_tmp) );
- p_adler_helper = abiinfo_both->host_ppc_calls_use_fndescrs
- ? ((HWord*)(&genericg_compute_adler32))[0]
- : (HWord)&genericg_compute_adler32;
+ if (abiinfo_both->host_ppc_calls_use_fndescrs) {
+ HWord* fndescr = (HWord*)&genericg_compute_adler32;
+ p_adler_helper = fndescr[0];
+ } else {
+ p_adler_helper = (HWord)&genericg_compute_adler32;
+ }
irsb->stmts[selfcheck_idx+4]
= IRStmt_Exit(
|
|
From: <sv...@va...> - 2008-10-23 09:53:03
|
Author: sewardj
Date: 2008-10-23 10:46:59 +0100 (Thu, 23 Oct 2008)
New Revision: 8697
Log:
gcc-4.4.0 (snapshot) started complaining about buf.sem_nsems being
uninitialised in get_sem_count(). This makes it quiet. I am not sure
whether get_sem_count() was correct or not without it (probably was
OK).
Modified:
trunk/coregrind/m_syswrap/syswrap-generic.c
Modified: trunk/coregrind/m_syswrap/syswrap-generic.c
===================================================================
--- trunk/coregrind/m_syswrap/syswrap-generic.c 2008-10-22 15:49:59 UTC (rev 8696)
+++ trunk/coregrind/m_syswrap/syswrap-generic.c 2008-10-23 09:46:59 UTC (rev 8697)
@@ -1580,6 +1580,11 @@
union vki_semun arg;
SysRes res;
+ /* Doesn't actually seem to be necessary, but gcc-4.4.0 20081017
+ (experimental) otherwise complains that the use in the return
+ statement below is uninitialised. */
+ buf.sem_nsems = 0;
+
arg.buf = &buf;
# ifdef __NR_semctl
@@ -1587,7 +1592,7 @@
# else
res = VG_(do_syscall5)(__NR_ipc, 3 /* IPCOP_semctl */, semid, 0,
VKI_IPC_STAT, (UWord)&arg);
-# endif
+# endif
if (res.isError)
return 0;
|
|
From: Tom H. <th...@cy...> - 2008-10-23 03:32:06
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2008-10-23 03:15:02 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 == 367 tests, 81 stderr failures, 2 stdout failures, 29 post failures == 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/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) helgrind/tests/hg01_all_ok (stderr) helgrind/tests/hg02_deadlock (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/hg06_readshared (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc02_simple_tls (stderr) helgrind/tests/tc03_re_excl (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc07_hbl1 (stderr) helgrind/tests/tc08_hbl2 (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc11_XCHG (stderr) helgrind/tests/tc12_rwl_trivial (stderr) helgrind/tests/tc14_laog_dinphils (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) helgrind/tests/tc24_nonzero_sem (stderr) massif/tests/alloc-fns-A (post) massif/tests/alloc-fns-B (post) massif/tests/basic (post) massif/tests/basic2 (post) massif/tests/big-alloc (post) massif/tests/culling1 (stderr) massif/tests/culling2 (stderr) massif/tests/custom_alloc (post) massif/tests/deep-A (post) massif/tests/deep-B (stderr) massif/tests/deep-B (post) massif/tests/deep-C (stderr) massif/tests/deep-C (post) massif/tests/deep-D (post) massif/tests/ignoring (post) massif/tests/insig (post) massif/tests/long-names (post) massif/tests/long-time (post) massif/tests/new-cpp (post) massif/tests/null (post) massif/tests/one (post) massif/tests/overloaded-new (post) massif/tests/peak (post) massif/tests/peak2 (stderr) massif/tests/peak2 (post) massif/tests/realloc (stderr) massif/tests/realloc (post) massif/tests/thresholds_0_0 (post) massif/tests/thresholds_0_10 (post) massif/tests/thresholds_10_0 (post) massif/tests/thresholds_10_10 (post) massif/tests/thresholds_5_0 (post) massif/tests/thresholds_5_10 (post) massif/tests/zero1 (post) massif/tests/zero2 (post) memcheck/tests/file_locking (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/long_namespace_xml (stderr) memcheck/tests/malloc_free_fill (stderr) memcheck/tests/origin1-yes (stderr) memcheck/tests/origin4-many (stderr) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_changes (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/x86/bug152022 (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/xor-undef-x86 (stderr) memcheck/tests/xml1 (stderr) none/tests/blockfault (stderr) none/tests/cmdline2 (stdout) none/tests/mremap2 (stdout) none/tests/shell (stderr) none/tests/shell_valid1 (stderr) none/tests/shell_valid2 (stderr) none/tests/shell_valid3 (stderr) |
|
From: Tom H. <th...@cy...> - 2008-10-23 03:23:43
|
Nightly build on lloyd ( x86_64, Fedora 7 ) started at 2008-10-23 03:05:26 BST 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 == 461 tests, 12 stderr failures, 3 stdout failures, 0 post failures == exp-ptrcheck/tests/base (stderr) exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc22_exit_w_lock (stderr) memcheck/tests/file_locking (stderr) memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/scalar (stderr) none/tests/blockfault (stderr) none/tests/cmdline2 (stdout) none/tests/mremap2 (stdout) ================================================= == 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 == 461 tests, 13 stderr failures, 3 stdout failures, 0 post failures == exp-ptrcheck/tests/bad_percentify (stderr) exp-ptrcheck/tests/base (stderr) exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc22_exit_w_lock (stderr) memcheck/tests/file_locking (stderr) memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/scalar (stderr) none/tests/blockfault (stderr) none/tests/cmdline2 (stdout) none/tests/mremap2 (stdout) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Thu Oct 23 03:43:04 2008 --- new.short Thu Oct 23 04:23:38 2008 *************** *** 8,11 **** ! == 461 tests, 13 stderr failures, 3 stdout failures, 0 post failures == ! exp-ptrcheck/tests/bad_percentify (stderr) exp-ptrcheck/tests/base (stderr) --- 8,10 ---- ! == 461 tests, 12 stderr failures, 3 stdout failures, 0 post failures == exp-ptrcheck/tests/base (stderr) |
|
From: Tom H. <th...@cy...> - 2008-10-23 03:02:14
|
Nightly build on trojan ( x86_64, Fedora Core 6 ) started at 2008-10-23 03:25:19 BST 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 == 465 tests, 14 stderr failures, 5 stdout failures, 0 post failures == exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) memcheck/tests/file_locking (stderr) memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/bug133694 (stdout) memcheck/tests/x86/bug133694 (stderr) memcheck/tests/x86/scalar (stderr) none/tests/blockfault (stderr) none/tests/cmdline1 (stdout) none/tests/cmdline2 (stdout) none/tests/mremap2 (stdout) ================================================= == 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 == 465 tests, 14 stderr failures, 5 stdout failures, 0 post failures == exp-ptrcheck/tests/bad_percentify (stderr) exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) memcheck/tests/file_locking (stderr) memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/bug133694 (stdout) memcheck/tests/x86/bug133694 (stderr) memcheck/tests/x86/scalar (stderr) none/tests/blockfault (stderr) none/tests/cmdline1 (stdout) none/tests/cmdline2 (stdout) none/tests/mremap2 (stdout) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Thu Oct 23 03:43:02 2008 --- new.short Thu Oct 23 04:02:04 2008 *************** *** 9,11 **** == 465 tests, 14 stderr failures, 5 stdout failures, 0 post failures == - exp-ptrcheck/tests/bad_percentify (stderr) exp-ptrcheck/tests/ccc (stderr) --- 9,10 ---- *************** *** 14,15 **** --- 13,15 ---- exp-ptrcheck/tests/pth_specific (stderr) + helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc20_verifywrap (stderr) |
|
From: Tom H. <th...@cy...> - 2008-10-23 02:33:42
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2008-10-23 03:00:02 BST 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 == 467 tests, 34 stderr failures, 5 stdout failures, 0 post failures == drd/tests/pth_cancel_locked (stderr) drd/tests/pth_detached2 (stdout) exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/hackedbz2 (stderr) helgrind/tests/hg01_all_ok (stderr) helgrind/tests/hg02_deadlock (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc14_laog_dinphils (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) memcheck/tests/file_locking (stderr) memcheck/tests/malloc_free_fill (stderr) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/varinfo6 (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/amd64/insn_ssse3 (stdout) none/tests/amd64/insn_ssse3 (stderr) none/tests/amd64/ssse3_misaligned (stderr) none/tests/blockfault (stderr) none/tests/cmdline2 (stdout) none/tests/fdleak_fcntl (stderr) none/tests/mremap2 (stdout) none/tests/x86/insn_ssse3 (stdout) none/tests/x86/insn_ssse3 (stderr) none/tests/x86/ssse3_misaligned (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 == 467 tests, 35 stderr failures, 4 stdout failures, 0 post failures == drd/tests/pth_cancel_locked (stderr) exp-ptrcheck/tests/bad_percentify (stderr) exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/hackedbz2 (stderr) helgrind/tests/hg01_all_ok (stderr) helgrind/tests/hg02_deadlock (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc14_laog_dinphils (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) memcheck/tests/file_locking (stderr) memcheck/tests/malloc_free_fill (stderr) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/varinfo6 (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/amd64/insn_ssse3 (stdout) none/tests/amd64/insn_ssse3 (stderr) none/tests/amd64/ssse3_misaligned (stderr) none/tests/blockfault (stderr) none/tests/cmdline2 (stdout) none/tests/fdleak_fcntl (stderr) none/tests/mremap2 (stdout) none/tests/x86/insn_ssse3 (stdout) none/tests/x86/insn_ssse3 (stderr) none/tests/x86/ssse3_misaligned (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Thu Oct 23 03:14:06 2008 --- new.short Thu Oct 23 03:33:28 2008 *************** *** 8,12 **** ! == 467 tests, 35 stderr failures, 4 stdout failures, 0 post failures == drd/tests/pth_cancel_locked (stderr) ! exp-ptrcheck/tests/bad_percentify (stderr) exp-ptrcheck/tests/ccc (stderr) --- 8,12 ---- ! == 467 tests, 34 stderr failures, 5 stdout failures, 0 post failures == drd/tests/pth_cancel_locked (stderr) ! drd/tests/pth_detached2 (stdout) exp-ptrcheck/tests/ccc (stderr) |
|
From: MoJiong Q. <qm...@ho...> - 2008-10-23 01:49:18
|
Please forget previous html-formatted mail. -------------------------------------------------- Hello guys, I was playing Valgrind in VMware virtual machine, and found Valgrind doesn't work with VMware backdoor. (Please see below for a brief introduction of VMware backdoor.) Specifically, Valgrind reports two kinds of errors when running open-vm-tools and programs that use VMware backdoors: Segementation fault, due to in/out; And illegal instruction, due to ins/outs not handled in Valgrind. The attachment is a patch to fix the problem. I used Valgrind-3.1.1 (http://valgrind.org/downloads/valgrind-3.3.1.tar.bz2) as a code base. Roughly three changes in the patch: - Support ins/outs. Added corresponding decoding stub in VEX/priv/guest-x86(amd64)/toIR.c, and dirtyhelpers in ghelper.c - Added a new function process_vmware_backdoor in ghelper.c. The dirtyhelpers for in, out, ins and outs call process_vmware_backdoor. - Added code to process 8-bit memory chunk in memcheck/mc_translate.c/do_shadow_Dirty, because ins/outs produce 8-bit memory inputs. This patch doesn't change the original behavior when running on non-VMware systems. And it doesn't bring performance problem, since no normal application does port I/O. Considering VMware virtual machines are widely used, I think it is deservable for Valgrind to support VMware virtual machines. It would be great if you can take a look at the patch and finally merged it into Valgrind. About VMware backdoor: A user program running in a VMware virtual machine can communicate with VMM through so-called VMware backdoor. The commnucation is done by accessing a special I/O port and setting pre-defined value to EAX. VMware VMM redefines in/out/ins/outs meeting these two conditions to take arbitrary other registers as input and allow these four instructions to write to arbitrary other registers as output. The link (http://chitchat.at.infoseek.co.jp/vmware/backdoor.html) has some description. It talked about backdoor through in/out, but not ins/outs, which are actually also used by VMware as backdoor triggering instrucitons. Thanks, Mojiong _________________________________________________________________ Explore the seven wonders of the world http://search.msn.com/results.aspx?q=7+wonders+world&mkt=en-US&form=QBRE |
|
From: MoJiong Q. <qm...@ho...> - 2008-10-23 01:11:23
|
Hello guys, I was playing Valgrind in VMware virtual machine, and found Valgrind doesn't work with VMware backdoor. (Please see below for a brief introduction of VMware backdoor.) Specifically, Valgrind reports two kinds of errors when running open-vm-tools and programs that use VMware backdoors: Segementation fault, due to in/out; And illegal instruction, due to ins/outs not handled in Valgrind. The attachment is a patch to fix the problem. I used Valgrind-3.1.1 (http://valgrind.org/downloads/valgrind-3.3.1.tar.bz2) as a code base. Roughly three changes in the patch: - Support ins/outs. Added corresponding decoding stub in VEX/priv/guest-x86(amd64)/toIR.c, and dirtyhelpers in ghelper.c - Added a new function process_vmware_backdoor in ghelper.c. The dirtyhelpers for in, out, ins and outs call process_vmware_backdoor. - Added code to process 8-bit memory chunk in memcheck/mc_translate.c/do_shadow_Dirty, because ins/outs produce 8-bit memory inputs. This patch doesn't change the original behavior when running on non-VMware systems. And it doesn't bring performance problem, since no normal application does port I/O. Considering VMware virtual machines are widely used, I think it is deservable for Valgrind to support VMware virtual machines. It would be great if you can take a look at the patch and finally merged it into Valgrind. About VMware backdoor:A user program running in a VMware virtual machine can communicate with VMM through so-called VMware backdoor. The commnucation is done by accessing a special I/O port and setting pre-defined value to EAX. VMware VMM redefines in/out/ins/outs meeting these two conditions to take arbitrary other registers as input and allow these four instructions to write to arbitrary other registers as output. The link (http://chitchat.at.infoseek.co.jp/vmware/backdoor.html) has some description. It talked about backdoor through in/out, but not ins/outs, which are actually also used by VMware as backdoor triggering instrucitons. Thanks,Mojiong _________________________________________________________________ Explore the seven wonders of the world http://search.msn.com/results.aspx?q=7+wonders+world&mkt=en-US&form=QBRE |
|
From: <sv...@va...> - 2008-10-22 15:50:09
|
Author: sewardj
Date: 2008-10-22 16:49:59 +0100 (Wed, 22 Oct 2008)
New Revision: 8696
Log:
Don't assert on icc9 generated Dwarf3.
Modified:
trunk/coregrind/m_debuginfo/readdwarf3.c
Modified: trunk/coregrind/m_debuginfo/readdwarf3.c
===================================================================
--- trunk/coregrind/m_debuginfo/readdwarf3.c 2008-10-22 09:21:09 UTC (rev 8695)
+++ trunk/coregrind/m_debuginfo/readdwarf3.c 2008-10-22 15:49:59 UTC (rev 8696)
@@ -3760,10 +3760,14 @@
ML_(dinfo_free)( tyents_to_keep_cache );
tyents_to_keep_cache = NULL;
- /* and the file name table (just the array, not the entries
- themselves). */
- vg_assert(varparser.filenameTable);
- VG_(deleteXA)( varparser.filenameTable );
+ /* and the file name table (just the array, not the entries
+ themselves). (Apparently, 2008-Oct-23, varparser.filenameTable
+ can be NULL here, for icc9 generated Dwarf3. Not sure what that
+ signifies (a deeper problem with the reader?)) */
+ if (varparser.filenameTable) {
+ VG_(deleteXA)( varparser.filenameTable );
+ varparser.filenameTable = NULL;
+ }
/* record the GExprs in di so they can be freed later */
vg_assert(!di->admin_gexprs);
|