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
(12) |
|
2
(6) |
3
(13) |
4
(9) |
5
(6) |
6
(8) |
7
(5) |
8
(5) |
|
9
(15) |
10
(18) |
11
(18) |
12
(18) |
13
(7) |
14
(11) |
15
(6) |
|
16
(12) |
17
(28) |
18
(15) |
19
(12) |
20
(17) |
21
(23) |
22
(10) |
|
23
(9) |
24
(11) |
25
(7) |
26
(21) |
27
(12) |
28
(6) |
29
(6) |
|
30
(8) |
|
|
|
|
|
|
|
From: <sv...@va...> - 2007-09-13 23:19:00
|
Author: sewardj
Date: 2007-09-14 00:18:58 +0100 (Fri, 14 Sep 2007)
New Revision: 6829
Log:
Add initial documentation.
Modified:
branches/THRCHECK/docs/xml/manual.xml
branches/THRCHECK/thrcheck/docs/tc-manual.xml
Modified: branches/THRCHECK/docs/xml/manual.xml
===================================================================
--- branches/THRCHECK/docs/xml/manual.xml 2007-09-12 22:09:33 UTC (rev 6828)
+++ branches/THRCHECK/docs/xml/manual.xml 2007-09-13 23:18:58 UTC (rev 6829)
@@ -28,12 +28,10 @@
xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="../../callgrind/docs/cl-manual.xml" parse="xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="../../thrcheck/docs/tc-manual.xml" parse="xml"
+ 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="../../helgrind/docs/hg-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: branches/THRCHECK/thrcheck/docs/tc-manual.xml
===================================================================
--- branches/THRCHECK/thrcheck/docs/tc-manual.xml 2007-09-12 22:09:33 UTC (rev 6828)
+++ branches/THRCHECK/thrcheck/docs/tc-manual.xml 2007-09-13 23:18:58 UTC (rev 6829)
@@ -3,104 +3,279 @@
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
-<chapter id="hg-manual" xreflabel="Helgrind: a data-race detector">
- <title>Helgrind: a data-race detector</title>
+<chapter id="tc-manual" xreflabel="Thrcheck: thread error detector">
+ <title>Thrcheck: a thread error detector</title>
<para>To use this tool, you must specify
-<computeroutput>--tool=helgrind</computeroutput> on the Valgrind
+<computeroutput>--tool=thrcheck</computeroutput> on the Valgrind
command line.</para>
-<para>Note: Helgrind does not work in Valgrind 3.1.0. We hope
-to reinstate in version 3.2.0.</para>
+<sect1 id="tc-manual.overview" xreflabel="Overview">
+<title>Overview</title>
-<sect1 id="hg-manual.data-races" xreflabel="Data Races">
-<title>Data Races</title>
+<para>Thrcheck is a Valgrind tool for detecting threading errors in C,
+C++ and Fortran programs that use the POSIX Pthreads library.</para>
-<para>Helgrind is a valgrind tool for detecting data races in C and C++
-programs that use the Pthreads library.</para>
+<para>The main abstractions in POSIX Pthreads are: a set of threads
+sharing a common address space, mutexes (locks), condition variables
+(inter-thread event notifications), thread creation, thread joinage
+and thread exit.</para>
-<para>It uses the Eraser algorithm described in:
+<para>Thrcheck can detect three the following three classes of
+errors:</para>
- <address>Eraser: A Dynamic Data Race Detector for Multithreaded Programs
- Stefan Savage, Michael Burrows, Greg Nelson, Patrick Sobalvarro and Thomas Anderson
- ACM Transactions on Computer Systems, 15(4):391-411
- November 1997.
- </address>
-</para>
+<orderedlist>
+ <listitem>
+ <para>Misuses of the POSIX Pthreads API. Because the tool observes all
+ significant thread events (creation, joinage, exit, lock, unlock,
+ wait, signal, broadcast), it can report various common problems:</para>
+ <itemizedlist>
+ <listitem><para>unlocking a not-locked mutex</para></listitem>
+ <listitem><para>unlocking a mutex held by a different
+ thread</para></listitem>
+ <listitem><para>recursively locking a non-recursive mutex</para></listitem>
+ <listitem><para>waiting for a condition variable without holding
+ the associated mutex</para></listitem>
+ <listitem><para>inconsistent association of mutex and condition
+ variables in pthread_cond_wait</para></listitem>
+ <listitem><para>threads which exit while holding locked
+ mutexes</para></listitem>
+ <listitem><para>deallocation of memory that contains a
+ locked mutex</para></listitem>
+ </itemizedlist>
+ </listitem>
-<para>We also incorporate significant improvements from this paper:
+ <listitem>
+ <para>Potential deadlocks arising from lock ordering problems. If
+ threads must acquire more than one lock before accessing some shared
+ resource, then all threads must acquire those locks in the same
+ order. Not doing so risks deadlock. Detecting such inconsistencies
+ is useful because, whilst actual deadlocks are fairly obvious,
+ potential deadlocks may never be discovered during testing and could
+ later lead to hard-to-diagnose in-service failures.
+ </para>
+ <para>
+ Detecting such problems is a simple matter of keeping track of
+ observed lock acquisition orderings and reporting when new
+ acquisitions violate the existing ordering.</para>
+ </listitem>
- <address>Runtime Checking of Multithreaded Applications with Visual Threads
- Jerry J. Harrow, Jr.
- Proceedings of the 7th International SPIN Workshop on Model Checking of Software
- Stanford, California, USA
- August 2000
- LNCS 1885, pp331--342
- K. Havelund, J. Penix, and W. Visser, editors.
- </address>
-</para>
+ <listitem>
+ <para>Data races. A data race happens, or could happen, when two threads
+ access a shared memory location without using suitable locks to
+ ensure single-threaded access. Such missing locking can cause
+ obscure timing dependent bugs. Ensuring programs are race-free is
+ one of the central difficulties of threaded programming.</para>
+ </listitem>
+</orderedlist>
</sect1>
-<sect1 id="hg-manual.what-does" xreflabel="What Helgrind Does">
-<title>What Helgrind Does</title>
+<sect1 id="tc-manual.data-races" xreflabel="Data Races">
+<title>Data Races</title>
-<para>Basically what Helgrind does is to look for memory
-locations which are accessed by more than one thread. For each
-such location, Helgrind records which of the program's
-(pthread_mutex_)locks were held by the accessing thread at the
-time of the access. The hope is to discover that there is indeed
-at least one lock which is used by all threads to protect that
-location. If no such lock can be found, then there is
-(apparently) no consistent locking strategy being applied for
-that location, and so a possible data race might result.</para>
+This section describes Thrcheck's data race detection in more detail.
-<para>Helgrind also allows for "thread segment lifetimes". If
-the execution of two threads cannot overlap -- for example, if
-your main thread waits on another thread with a
-<computeroutput>pthread_join()</computeroutput> operation -- they
-can both access the same variable without holding a lock.</para>
+<para>In short, what Thrcheck does is to look for memory locations
+which are accessed by more than one thread. For each such location,
+Thrcheck records which of the program's (pthread_mutex_)locks were
+held by the accessing thread at the time of each access. The hope is
+to discover that there is indeed at least one lock which is
+consistently used by all threads to protect that location. If no such
+lock can be found, then there is apparently no consistent locking
+strategy being applied for that location, and so a possible data race
+might result.</para>
-<para>There's a lot of other sophistication in Helgrind, aimed at
-reducing the number of false reports, and at producing useful
-error reports. We hope to have more documentation one
-day ... </para>
+<para>In practice this discipline is far too simplistic,
+and is unusable since it reports many races in some widely used
+and known-correct programming disciplines. Thrcheck's checking
+therefore incorporates many refinements to this basic idea, and
+can be summarised as follows:</para>
+<para>The following thread events are intercepted and monitored:</para>
+
+<itemizedlist>
+ <listitem><para>thread creation and exiting (pthread_create,
+ pthread_join, pthread_exit)</para>
+ </listitem>
+ <listitem>
+ <para>lock acquisition and release (pthread_mutex_lock,
+ pthread_mutex_unlock, and variants)</para>
+ </listitem>
+ <listitem>
+ <para>inter-thread event notifications (pthread_cond_wait,
+ pthread_cond_signal, pthread_cond_broadcast)</para>
+ </listitem>
+</itemizedlist>
+
+<para>Memory allocation and deallocation events are intercepted and
+monitored:</para>
+
+<itemizedlist>
+ <listitem>
+ <para>malloc/new/free/delete and variants</para>
+ </listitem>
+ <listitem>
+ <para>stack allocation and deallocation</para>
+ </listitem>
+</itemizedlist>
+
+<para>All memory accesses are intercepted and monitored.</para>
+
+<para>By observing the above events, Thrcheck can infer certain
+aspects of the program's locking discipline. Programs which adhere to
+the are considered to be acceptable:
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>A thread may allocate memory, and write initial values into
+ it, without locking. That thread is regarded as owning the memory
+ exclusively.</para>
+ </listitem>
+ <listitem>
+ <para>A thread may read and write memory which it owns exclusively,
+ without locking.</para>
+ </listitem>
+ <listitem>
+ <para>Memory which is owned exclusively by one thread may be read by
+ that thread and others without locking. However, in this situation
+ no thread may do unlocked writes to the memory (except for the owner
+ thread's initializing write).</para>
+ </listitem>
+ <listitem>
+ <para>Memory which is shared between multiple threads, one or more
+ of which writes to it, must be protected by a lock which is
+ correctly acquired and released by all threads accessing the
+ memory.</para>
+ </listitem>
+</itemizedlist>
+
+<para>Any violation of this discipline will cause an error to be reported.
+However, two exemptions apply:</para>
+
+<itemizedlist>
+ <listitem>
+ <para>A thread Y can acquire exclusive ownership of memory
+ previously owned exclusively by a different thread X providing the
+ X's last access and Y's first access are separated by one of the
+ following synchronization events: X creates thread Y, or X uses a
+ condition-variable to signal at Y, and Y is waiting for that event.
+ </para>
+ <para>
+ This refinement allows Thrcheck to correctly track the ownership
+ state of inter-thread buffers used in the worker-thread and
+ worker-thread-pool concurrent programming idioms (styles).
+</para>
+ </listitem>
+ <listitem>
+ <para>Similarly, if Y later joins back to X, memory exclusively
+ owned by Y becomes exclusively owned by X instead. Also, memory
+ that has been shared only by X and Y becomes exclusively owned by X.
+ More generally, memory that has been shared by X, Y and some
+ arbitrary other set S of threads is re-marked as shared by X and S.
+ Hence, under the right circumstances, memory shared amongst multiple
+ threads, all of which join into just one, can revert to the
+ exclusive ownership state.</para>
+ <para>
+ In effect, each memory location may make arbitrarily many
+ transitions between exclusive and shared ownership. Furthermore, a
+ different lock may protect the location during each period of shared
+ ownership. This significantly enhances the flexibility of the
+ algorithm.
+ </para>
+ </listitem>
+</itemizedlist>
+
+<para>The ownership state, accessing thread-set and related lock-set
+for each memory location are tracked at 32-bit granularity. This keeps
+the memory overhead tolerable, but it means the algorithm is imprecise
+for 16- and 8-bit memory accesses. Future work may lead to an
+implementation capable of tracking memory at 8-bit granularity
+without excessive space and time overheads.</para>
+
</sect1>
+<sect1 id="tc-manual.options" xreflabel="Thrcheck Options">
+<title>Thrcheck Options</title>
-<sect1 id="hg-manual.options" xreflabel="Helgrind Options">
-<title>Helgrind Options</title>
+<para>Currently there is only one Thrcheck-specific option:</para>
-<para>Helgrind-specific options are:</para>
-
<!-- start of xi:include in the manpage -->
-<variablelist id="hg.opts.list">
+<variablelist id="tc.opts.list">
- <varlistentry id="opt.private-stacks" xreflabel="--private-stacks">
+ <varlistentry id="opt.happens-before" xreflabel="--happens-before">
<term>
- <option><![CDATA[--private-stacks=<yes|no> [default: no] ]]></option>
+ <option><![CDATA[--happens-before=none|threads|condvars
+ [default: condvars] ]]></option>
</term>
<listitem>
- <para>Assume thread stacks are used privately.</para>
+ <para>This option is mostly useful for debugging Thrcheck
+ itself. It isn't much use to end users and is a bit difficult
+ to explain.
+ </para>
+ <para>Thrcheck always regards locks as the basis for
+ inter-thread synchronisation. However, by default, before
+ reporting a race error, Thrcheck will also check whether
+ certain other kinds of inter-thread synchronisation events
+ happened. It may be that if such events took place, then no
+ race really occurred, and so no error needs to be reported.
+ This enables Thrcheck to correctly handle the
+ worker-thread and worker-thread-pool idioms.
+ </para>
+ <para>With <varname>--happens-before=condvars</varname>, both
+ thread creation/joinage, and condition variable
+ signal/broadcast/waits are regarded as sources of
+ synchronisation, and so both the worker-thread and
+ worker-thread-pool idioms are correctly handled. "Correctly
+ handled" means that Thrcheck will not falsely report race
+ errors for correct uses of these idioms.
+ </para>
+ <para>With <varname>--happens-before=threads</varname>, only
+ thread creation/joinage events are regarded as sources of
+ synchronisation, and so only the worker-thread idiom is
+ correctly handled. The worker-thread-pool is not correctly
+ handled.
+ </para>
+ <para>With <varname>--happens-before=none</varname>, no events
+ (apart, of course, from locking) are regarded as sources of
+ synchronisation. And so neither the worker-thread nor
+ worker-thread-pool idioms are correctly handled.
+ </para>
+ <para>Changing this setting from the default will increase your
+ false-error rate but give little or no gain. The only advantage
+ is that <option>--happens-before=threads</option> and
+ <option>--happens-before=none</option> should make Thrcheck
+ less and less sensitive to the scheduling of threads, and hence
+ the output more and more repeatable across runs.
+ </para>
</listitem>
</varlistentry>
- <varlistentry id="opt.show-last-access" xreflabel="--show-last-access">
- <term>
- <option><![CDATA[--show-last-access=<yes|some|no> [default: no] ]]></option>
- </term>
- <listitem>
- <para>Show location of last word access on error.</para>
- </listitem>
- </varlistentry>
-
</variablelist>
<!-- end of xi:include in the manpage -->
</sect1>
+
+<sect1 id="tc-manual.otherstuff" xreflabel="Other Stuff">
+<title>Other Stuff</title>
+
+<para>FIXME: this section will contain other stuff that it is
+important to document:</para>
+
+<itemizedlist>
+ <listitem><para>LOCK prefixes on x86/amd64
+ instructions</para></listitem>
+ <listitem><para>Reader-writer locks, and semaphores?
+ </para></listitem>
+ <listitem><para>Other stuff I forgot?
+ </para></listitem>
+</itemizedlist>
+
+</sect1>
+
</chapter>
|
|
From: <js...@ac...> - 2007-09-13 12:42:24
|
Nightly build on minnie ( SuSE 10.0, ppc32 ) started at 2007-09-13 09:00:01 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 == 220 tests, 10 stderr failures, 6 stdout failures, 0 posttest failures == memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_changes (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-fp (stderr) none/tests/ppc32/round (stdout) none/tests/ppc32/round (stderr) none/tests/ppc32/test_fx (stdout) none/tests/ppc32/test_fx (stderr) none/tests/ppc32/test_gx (stdout) |
|
From: Tom H. <th...@cy...> - 2007-09-13 02:31:10
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2007-09-13 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 == 256 tests, 27 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/addressable (stderr) memcheck/tests/badjump (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/erringfds (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-pool-0 (stderr) memcheck/tests/leak-pool-1 (stderr) memcheck/tests/leak-pool-2 (stderr) memcheck/tests/leak-pool-3 (stderr) memcheck/tests/leak-pool-4 (stderr) memcheck/tests/leak-pool-5 (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/long_namespace_xml (stderr) memcheck/tests/match-overrun (stderr) memcheck/tests/partial_load_dflt (stderr) memcheck/tests/partial_load_ok (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigkill (stderr) memcheck/tests/stack_changes (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/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2007-09-13 02:23:37
|
Nightly build on dellow ( x86_64, Fedora 7 ) started at 2007-09-13 03:10:04 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 == 293 tests, 4 stderr failures, 3 stdout failures, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/pth_detached (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 == 293 tests, 4 stderr failures, 4 stdout failures, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/pth_cvsimple (stdout) none/tests/pth_detached (stdout) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Thu Sep 13 03:16:53 2007 --- new.short Thu Sep 13 03:23:33 2007 *************** *** 8,10 **** ! == 293 tests, 4 stderr failures, 4 stdout failures, 0 posttest failures == memcheck/tests/pointer-trace (stderr) --- 8,10 ---- ! == 293 tests, 4 stderr failures, 3 stdout failures, 0 posttest failures == memcheck/tests/pointer-trace (stderr) *************** *** 15,17 **** none/tests/mremap2 (stdout) - none/tests/pth_cvsimple (stdout) none/tests/pth_detached (stdout) --- 15,16 ---- |
|
From: Tom H. <th...@cy...> - 2007-09-13 02:17:30
|
Nightly build on lloyd ( x86_64, Fedora Core 3 ) started at 2007-09-13 03:05:05 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 == 293 tests, 6 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2007-09-13 02:16:01
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2007-09-13 03:00:03 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 == 295 tests, 6 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/fdleak_fcntl (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: <js...@ac...> - 2007-09-13 00:17:33
|
Nightly build on g5 ( SuSE 10.1, ppc970 ) started at 2007-09-13 02:00:01 CEST 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 == 228 tests, 6 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/pointer-trace (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |