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
(5) |
2
(15) |
3
(20) |
|
4
(4) |
5
(11) |
6
(8) |
7
(36) |
8
(23) |
9
(6) |
10
(4) |
|
11
(4) |
12
(19) |
13
(17) |
14
(33) |
15
(16) |
16
(17) |
17
(4) |
|
18
(4) |
19
(30) |
20
(22) |
21
(23) |
22
(29) |
23
(20) |
24
(12) |
|
25
(7) |
26
(33) |
27
(10) |
28
(12) |
29
(19) |
30
(15) |
31
(8) |
|
From: <sv...@va...> - 2009-01-02 23:21:59
|
Author: sewardj Date: 2009-01-02 23:21:54 +0000 (Fri, 02 Jan 2009) New Revision: 8899 Log: Late entrant for 3.4.0 (sigh) Modified: trunk/NEWS Modified: trunk/NEWS =================================================================== --- trunk/NEWS 2009-01-02 23:19:26 UTC (rev 8898) +++ trunk/NEWS 2009-01-02 23:21:54 UTC (rev 8899) @@ -24,7 +24,7 @@ slowly. * A version (1.4.0) of the Valkyrie GUI, that works with Memcheck in - 3.4.0, will be released at the same time as 3.4.0. + 3.4.0, will be released shortly. * Helgrind's race detection algorithm has been completely redesigned and reimplemented, to address usability and scalability concerns: @@ -174,7 +174,7 @@ descriptions of data addresses in the error messages they create. (3.4.0.RC1: 24 Dec 2008, vex r1878, valgrind r8882). -(3.4.0: 3 Jan 2009, vex r1878, valgrind r8898). +(3.4.0: 3 Jan 2009, vex r1878, valgrind r8899). |
|
From: <sv...@va...> - 2009-01-02 23:19:32
|
Author: sewardj Date: 2009-01-02 23:19:26 +0000 (Fri, 02 Jan 2009) New Revision: 8898 Log: --> 3.4.0 (first attempt) Modified: trunk/NEWS trunk/configure.in Modified: trunk/NEWS =================================================================== --- trunk/NEWS 2009-01-02 23:17:02 UTC (rev 8897) +++ trunk/NEWS 2009-01-02 23:19:26 UTC (rev 8898) @@ -174,6 +174,7 @@ descriptions of data addresses in the error messages they create. (3.4.0.RC1: 24 Dec 2008, vex r1878, valgrind r8882). +(3.4.0: 3 Jan 2009, vex r1878, valgrind r8898). Modified: trunk/configure.in =================================================================== --- trunk/configure.in 2009-01-02 23:17:02 UTC (rev 8897) +++ trunk/configure.in 2009-01-02 23:19:26 UTC (rev 8898) @@ -8,7 +8,7 @@ ##------------------------------------------------------------## # Process this file with autoconf to produce a configure script. -AC_INIT(Valgrind, 3.4.0.RC1, val...@li...) +AC_INIT(Valgrind, 3.4.0, val...@li...) AC_CONFIG_SRCDIR(coregrind/m_main.c) AM_CONFIG_HEADER(config.h) AM_INIT_AUTOMAKE([foreign]) |
|
From: <sv...@va...> - 2009-01-02 23:17:12
|
Author: sewardj
Date: 2009-01-02 23:17:02 +0000 (Fri, 02 Jan 2009)
New Revision: 8897
Log:
Suppress all races whose top frame is in libc.so. This is a not very
clever interim solution to the problem of Helgrind reporting lots of
false races in glibc's stdio functions, due to it not seeing the
relevant (inlined, alas) locking that glibc uses.
Modified:
trunk/glibc-2.34567-NPTL-helgrind.supp
Modified: trunk/glibc-2.34567-NPTL-helgrind.supp
===================================================================
--- trunk/glibc-2.34567-NPTL-helgrind.supp 2009-01-02 17:49:17 UTC (rev 8896)
+++ trunk/glibc-2.34567-NPTL-helgrind.supp 2009-01-02 23:17:02 UTC (rev 8897)
@@ -8,70 +8,72 @@
# These are generic cover-alls which catch a lot of stuff
# in various combinations of ld, libc and libpthread
#
+# Note this is heavyhanded and not very clever:
+#
+# - suppress anything that has its top frame in ld.so
+# That's fine, since it's mostly dynamic linking stuff,
+# which has various deliberate (harmless) races
+#
+# - suppress anything that has its top frame in libc.so.
+# This really isn't clever, since it could hide some
+# legitimate races. But the problem is, if we don't do
+# this, then loads of errors to do with stdio are reported, because
+# H fails to see glibc's internal locking/unlocking of FILE*s
+# as required by POSIX. A better solution is needed.
+
{
helgrind-glibc2X-001
Helgrind:Race
obj:/lib*/ld-2.*so*
}
+
# helgrind-glibc2X-002 was merged into helgrind-glibc2X-001
+
# helgrind-glibc2X-003 was merged into helgrind-glibc2X-001
+
{
helgrind-glibc2X-004
Helgrind:Race
obj:/lib*/libc-2.*so*
- obj:/lib*/libc-2.*so*
}
+
{
helgrind-glibc2X-005
Helgrind:Race
obj:/lib*/libpthread-2.*so*
obj:/lib*/libpthread-2.*so*
- obj:/lib*/libpthread-2.*so*
}
-{
- helgrind-glibc2X-006
- Helgrind:Race
- obj:/lib*/libpthread-2.*so*
- obj:/lib*/libpthread-2.*so*
- obj:/lib*/libc-2.*so*
-}
+
+# helgrind-glibc2X-006 was merged into helgrind-glibc2X-005
+
# helgrind-glibc2X-007 was merged into helgrind-glibc2X-001
+
{
helgrind-glibc2X-008
Helgrind:Race
obj:/lib*/libpthread-2.*so*
obj:/lib*/libc-2.*so*
}
-{
- helgrind-glibc2X-009
- Helgrind:Race
- obj:/lib*/libc-2.*so*
- fun:*
- obj:/lib*/libc-2.*so*
-}
+
+# helgrind-glibc2X-009 was merged into helgrind-glibc2X-004
+
# helgrind-glibc2X-010 was merged into helgrind-glibc2X-001
-{
- helgrind-glibc2X-011
- Helgrind:Race
- obj:/lib*/libc-2.*so*
- obj:/lib*/libpthread-2.*so*
-}
+
+# helgrind-glibc2X-011 was merged into helgrind-glibc2X-004
+
# helgrind-glibc2X-012 was merged into helgrind-glibc2X-001
+
# helgrind-glibc2X-013 was merged into helgrind-glibc2X-001
+
# helgrind-glibc2X-014 was merged into helgrind-glibc2X-001
+
+# helgrind-glibc2X-015 was merged into helgrind-glibc2X-004
+
{
- helgrind-glibc2X-015
- Helgrind:Race
- obj:/lib*/libc-2.*so*
- obj:/lib*/libdl-2.*so*
- obj:/lib*/ld-2.*so*
-}
-{
helgrind-glibc2X-016
Helgrind:Race
obj:/lib*/libpthread-2.*so*
obj:/lib*/ld-2.*so*
- obj:/lib*/ld-2.*so*
}
# These are very ugly. They are needed to suppress errors inside (eg)
@@ -252,3 +254,4 @@
# To do with dynamic linking
#
# helgrind---ld.so-...-dlsym was merged into helgrind-glibc2X-001
+
|
|
From: <sv...@va...> - 2009-01-02 17:49:23
|
Author: bart Date: 2009-01-02 17:49:17 +0000 (Fri, 02 Jan 2009) New Revision: 8896 Log: Updated ignore list. Modified: trunk/helgrind/tests/ Property changes on: trunk/helgrind/tests ___________________________________________________________________ Name: svn:ignore - .deps hg01_all_ok hg02_deadlock hg03_inherit hg04_race hg05_race2 hg06_readshared Makefile Makefile.in *.stderr.diff* *.stderr.out *.stdout.diff* *.stdout.out tc01_simple_race tc02_simple_tls tc03_re_excl tc04_free_lock tc05_simple_race tc06_two_races tc07_hbl1 tc08_hbl2 tc09_bad_unlock tc10_rec_lock tc11_XCHG tc12_rwl_trivial tc13_laog1 tc14_laog_dinphils tc15_laog_lockdel tc16_byterace tc17_sembar tc18_semabuse tc19_shadowmem tc20_verifywrap tc21_pthonce tc22_exit_w_lock tc23_bogus_condwait tc24_nonzero_sem + *.stderr.diff* *.stderr.out *.stdout.diff* *.stdout.out .deps bar_bad bar_trivial hg01_all_ok hg02_deadlock hg03_inherit hg04_race hg05_race2 hg06_readshared Makefile Makefile.in pth_barrier rwlock_race rwlock_test tc01_simple_race tc02_simple_tls tc03_re_excl tc04_free_lock tc05_simple_race tc06_two_races tc07_hbl1 tc08_hbl2 tc09_bad_unlock tc10_rec_lock tc11_XCHG tc12_rwl_trivial tc13_laog1 tc14_laog_dinphils tc15_laog_lockdel tc16_byterace tc17_sembar tc18_semabuse tc19_shadowmem tc20_verifywrap tc21_pthonce tc22_exit_w_lock tc23_bogus_condwait tc24_nonzero_sem |
|
From: <sv...@va...> - 2009-01-02 17:39:20
|
Author: bart
Date: 2009-01-02 17:39:07 +0000 (Fri, 02 Jan 2009)
New Revision: 8895
Log:
Added a new mutex type: libio_file.
Modified:
branches/DRDDEV/drd/drd_clientreq.h
branches/DRDDEV/drd/drd_mutex.c
Modified: branches/DRDDEV/drd/drd_clientreq.h
===================================================================
--- branches/DRDDEV/drd/drd_clientreq.h 2009-01-02 17:38:13 UTC (rev 8894)
+++ branches/DRDDEV/drd/drd_clientreq.h 2009-01-02 17:39:07 UTC (rev 8895)
@@ -201,7 +201,8 @@
mutex_type_recursive_mutex = 1,
mutex_type_errorcheck_mutex = 2,
mutex_type_default_mutex = 3,
- mutex_type_spinlock = 4
+ mutex_type_spinlock = 4,
+ mutex_type_libio_file = 5,
} MutexT;
typedef enum
Modified: branches/DRDDEV/drd/drd_mutex.c
===================================================================
--- branches/DRDDEV/drd/drd_mutex.c 2009-01-02 17:38:13 UTC (rev 8894)
+++ branches/DRDDEV/drd/drd_mutex.c 2009-01-02 17:39:07 UTC (rev 8895)
@@ -446,6 +446,8 @@
return "mutex";
case mutex_type_spinlock:
return "spinlock";
+ case mutex_type_libio_file:
+ return "libio_file";
default:
tl_assert(0);
}
|
|
From: <sv...@va...> - 2009-01-02 17:38:27
|
Author: bart
Date: 2009-01-02 17:38:13 +0000 (Fri, 02 Jan 2009)
New Revision: 8894
Log:
Removed ad-hoc FILE-I/O suppression patterns.
Modified:
branches/DRDDEV/glibc-2.X-drd.supp
Modified: branches/DRDDEV/glibc-2.X-drd.supp
===================================================================
--- branches/DRDDEV/glibc-2.X-drd.supp 2009-01-02 17:32:19 UTC (rev 8893)
+++ branches/DRDDEV/glibc-2.X-drd.supp 2009-01-02 17:38:13 UTC (rev 8894)
@@ -71,19 +71,6 @@
fun:random_r
}
{
- libc:stdio
- drd:ConflictingAccess
- ...
- fun:_IO_file_xsputn*
- fun:vfprintf
-}
-{
- libc:stdio
- drd:ConflictingAccess
- ...
- fun:fflush
-}
-{
librt
drd:ConflictingAccess
fun:__librt_enable_asynccancel
|
|
From: <sv...@va...> - 2009-01-02 17:32:25
|
Author: bart Date: 2009-01-02 17:32:19 +0000 (Fri, 02 Jan 2009) New Revision: 8893 Log: Make sure that the regression tests pass on a system with the glibc-debuginfo package installed. Modified: branches/DRDDEV/drd/tests/filter_stderr Modified: branches/DRDDEV/drd/tests/filter_stderr =================================================================== --- branches/DRDDEV/drd/tests/filter_stderr 2009-01-02 13:29:32 UTC (rev 8892) +++ branches/DRDDEV/drd/tests/filter_stderr 2009-01-02 17:32:19 UTC (rev 8893) @@ -15,6 +15,7 @@ -e "s/, in frame #[0-9]* of thread /, in frame #? of thread /" \ -e "s/(tc20_verifywrap.c:261)/(tc20_verifywrap.c:262)/" \ -e "/^Copyright (C) 2006-200., and GNU GPL'd, by Bart Van Assche.$/d" \ +-e "s/\([A-Za-z_]*\) (clone.S:[0-9]*)/\1 (in \/...libc...)/" \ -e "s/[A-Za-z_]* (pthread_create.c:[0-9]*)/(within libpthread-?.?.so)/" \ -e "s/[A-Za-z_]* (in [^ ]*libpthread-[0-9.]*\.so)/(within libpthread-?.?.so)/" \ -e "s:(within /lib[0-9]*/ld-[0-9.]*\.so):(within ld-?.?.so):" \ |
|
From: <sv...@va...> - 2009-01-02 13:29:41
|
Author: bart
Date: 2009-01-02 13:29:32 +0000 (Fri, 02 Jan 2009)
New Revision: 8892
Log:
Polished manual.
Modified:
trunk/drd/docs/drd-manual.xml
Modified: trunk/drd/docs/drd-manual.xml
===================================================================
--- trunk/drd/docs/drd-manual.xml 2009-01-02 11:07:18 UTC (rev 8891)
+++ trunk/drd/docs/drd-manual.xml 2009-01-02 13:29:32 UTC (rev 8892)
@@ -52,13 +52,14 @@
Multithreaded programs can use one or more of the following
paradigms. Which paradigm is appropriate a.o. depends on the
application type -- modeling concurrent activities versus HPC.
+Some examples of multithreaded programming paradigms are:
<itemizedlist>
<listitem>
<para>
Locking. Data that is shared between threads may only be
- accessed after a lock is obtained on the mutex associated with
- the shared data item. A.o. the POSIX threads library, the Qt
- library and the Boost.Thread library support this paradigm
+ accessed after a lock has been obtained on the mutex associated
+ with the shared data item. A.o. the POSIX threads library, the
+ Qt library and the Boost.Thread library support this paradigm
directly.
</para>
</listitem>
@@ -72,6 +73,17 @@
</listitem>
<listitem>
<para>
+ Automatic parallelization. A compiler converts a sequential
+ program into a multithreaded program. The original program may
+ or may not contain parallelization hints. As an example,
+ <computeroutput>gcc</computeroutput> supports the OpenMP
+ standard from gcc version 4.3.0 on. OpenMP is a set of compiler
+ directives which tell a compiler how to parallelize a C, C++ or
+ Fortran program.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
Software Transactional Memory (STM). Data is shared between
threads, and shared data is updated via transactions. After each
transaction it is verified whether there were conflicting
@@ -83,16 +95,6 @@
support to <computeroutput>gcc</computeroutput>.
</para>
</listitem>
- <listitem>
- <para>
- Automatic parallelization. A compiler converts a sequential
- program into a multithreaded program. The original program may
- or may not contain parallelization hints. As an example,
- <computeroutput>gcc</computeroutput> supports OpenMP from
- version 4.3.0 on. OpenMP is a set of compiler directives which
- tell a compiler how to parallelize a C, C++ or Fortran program.
- </para>
- </listitem>
</itemizedlist>
</para>
@@ -101,7 +103,7 @@
long as the implementation of these paradigms is based on the POSIX
threads primitives. DRD however does not support programs that use
e.g. Linux' futexes directly. Attempts to analyze such programs with
-DRD will result in false positives.
+DRD will cause DRD to report many false positives.
</para>
</sect2>
@@ -134,12 +136,14 @@
</listitem>
<listitem>
<para>
- Atomic store and load-modify-store operations. While these
- are not mentioned in the POSIX threads standard, most
+ Atomic store and load-modify-store operations. While these are
+ not mentioned in the POSIX threads standard, most
microprocessors support atomic memory operations. And some
compilers provide direct support for atomic memory operations
through built-in functions like
- e.g. <computeroutput>__sync_fetch_and_add()</computeroutput>.
+ e.g. <computeroutput>__sync_fetch_and_add()</computeroutput>
+ which is supported by both <computeroutput>gcc</computeroutput>
+ and <computeroutput>icc</computeroutput>.
</para>
</listitem>
<listitem>
@@ -161,9 +165,9 @@
<para>
Which source code statements generate which memory accesses depends on
-the memory model of the programming language being used. There is not
-yet a definitive memory model for the C and C++ languagues. For a
-draft memory model, see also document <ulink
+the <emphasis>memory model</emphasis> of the programming language
+being used. There is not yet a definitive memory model for the C and
+C++ languagues. For a draft memory model, see also document <ulink
url="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2338.html">
WG21/N2338</ulink>.
</para>
@@ -182,8 +186,8 @@
<title>Multithreaded Programming Problems</title>
<para>
-Depending on how multithreading is expressed in a program, one or more
-of the following problems can be triggered by a multithreaded program:
+Depending on which multithreading paradigm is being used in a program,
+one or more of the following problems can occur:
<itemizedlist>
<listitem>
<para>
@@ -224,10 +228,10 @@
<para>
Although the likelihood of the occurrence of data races can be reduced
-by a disciplined programming style, a tool for automatic detection of
-data races is a necessity when developing multithreaded software. DRD
-can detect these, as well as lock contention and improper use of the
-POSIX threads API.
+through a disciplined programming style, a tool for automatic
+detection of data races is a necessity when developing multithreaded
+software. DRD can detect these, as well as lock contention and
+improper use of the POSIX threads API.
</para>
</sect2>
@@ -316,9 +320,9 @@
</term>
<listitem>
<para>
- Print an error message if any mutex or writer lock is held
- longer than the specified time (in milliseconds). This option
- is intended to allow detection of lock contention.
+ Print an error message if any mutex or writer lock has been
+ held longer than the specified time (in milliseconds). This
+ option enables detecting lock contention.
</para>
</listitem>
</varlistentry>
@@ -332,8 +336,8 @@
<para>
Whether to report calls to
<function>pthread_cond_signal()</function> and
- <function>pthread_cond_broadcast()</function>where the mutex
- associated with the signal via
+ <function>pthread_cond_broadcast()</function> where the mutex
+ associated with the signal through
<function>pthread_cond_wait()</function> or
<function>pthread_cond_timed_wait()</function>is not locked at
the time the signal is sent. Sending a signal without holding
@@ -365,9 +369,9 @@
</term>
<listitem>
<para>
- Print an error message if a reader lock is held longer than
- the specified time (in milliseconds). This option is intended
- to allow detection of lock contention.
+ Print an error message if a reader lock has been held longer
+ than the specified time (in milliseconds). This option enables
+ detection of lock contention.
</para>
</listitem>
</varlistentry>
@@ -390,14 +394,15 @@
</term>
<listitem>
<para>
- Print stack usage at thread exit time. When there is a large
- number of threads created in a program it becomes important to
- limit the amount of virtual memory allocated for thread
- stacks. This option makes it possible to observe the maximum
- number of bytes that has been used by the client program for
- thread stacks. Note: the DRD tool allocates some temporary
- data on the client thread stack. The space needed for this
- temporary data is not reported via this option.
+ Print stack usage at thread exit time. When a program creates
+ a large number of threads it becomes important to limit the
+ amount of virtual memory allocated for thread stacks. This
+ option makes it possible to observe how much stack memory has
+ been used by each thread of the the client program. Note: the
+ DRD tool allocates some temporary data on the client thread
+ stack itself. The space necessary for this temporary data must
+ be allocated by the client program, but is not included in the
+ reported stack usage.
</para>
</listitem>
</varlistentry>
@@ -409,9 +414,9 @@
<para>
Display the names of global, static and stack variables when a
data race is reported. While this information can be very
- helpful, by default it is not loaded into memory since for big
- programs reading in all debug information at once may cause an
- out of memory error.
+ helpful, it is not loaded into memory by default. This is
+ because for big programs reading in all debug information at
+ once may cause an out of memory error.
</para>
</listitem>
</varlistentry>
@@ -421,7 +426,7 @@
<!-- start of xi:include in the manpage -->
<para>
The following options are available for monitoring the behavior of the
-process being analyzed with DRD:
+client program:
</para>
<variablelist id="drd.debugopts.list">
@@ -506,8 +511,8 @@
<title>Detected Errors: Data Races</title>
<para>
-DRD prints a message every time it detects a data race. You should be
-aware of the following when interpreting DRD's output:
+DRD prints a message every time it detects a data race. Please keep
+the following in mind when interpreting DRD's output:
<itemizedlist>
<listitem>
<para>
@@ -603,23 +608,24 @@
your program has been compiled with debug information (-g), this
call stack will include file names and line numbers. The two
bottommost frames in this call stack (<function>clone</function>
- and <function>start_thread</function>) show how the NPTL starts a
- thread. The third frame (<function>vg_thread_wrapper</function>)
- is added by DRD. The fourth frame
- (<function>thread_func</function>) is interesting because it
- shows the thread entry point, that is the function that has been
- passed as the third argument to
+ and <function>start_thread</function>) show how the NPTL starts
+ a thread. The third frame
+ (<function>vg_thread_wrapper</function>) is added by DRD. The
+ fourth frame (<function>thread_func</function>) is the first
+ interesting line because it shows the thread entry point, that
+ is the function that has been passed as the third argument to
<function>pthread_create()</function>.
</para>
</listitem>
<listitem>
<para>
Next, the allocation context for the conflicting address is
- displayed. For static and stack variables the allocation context
- is only shown when the option
+ displayed. For dynamically allocated data the allocation call
+ stack is shown. For static variables and stack variables the
+ allocation context is only shown when the option
<computeroutput>--var-info=yes</computeroutput> has been
specified. Otherwise DRD will print <computeroutput>Allocation
- context: unknown</computeroutput> for such variables.
+ context: unknown</computeroutput>.
</para>
</listitem>
<listitem>
@@ -664,22 +670,19 @@
<title>Detected Errors: Lock Contention</title>
<para>
-Threads should be able to make progress without being blocked by other
-threads. Unfortunately this is not always true. Sometimes a thread
-has to wait until a mutex or reader-writer lock is unlocked by another
-thread. This is called <emphasis>lock contention</emphasis>. The more
-granular the locks are, the less likely lock contention will
-occur. The most unfortunate situation occurs when I/O is performed
-while a lock is held.
+Threads must be able to make progress without being blocked for too
+long by other threads. Sometimes a thread has to wait until a mutex or
+reader-writer lock is unlocked by another thread. This is called
+<emphasis>lock contention</emphasis>.
</para>
<para>
-Lock contention causes delays and hence should be avoided. The two
-command line options
+Lock contention causes delays. Such delays should be as short as
+possible. The two command line options
<literal>--exclusive-threshold=<n></literal> and
<literal>--shared-threshold=<n></literal> make it possible to
-detect lock contention by making DRD report any lock that is held
-longer than the specified threshold. An example:
+detect excessive lock contention by making DRD report any lock that
+has been held longer than the specified threshold. An example:
</para>
<programlisting><![CDATA[
$ valgrind --tool=drd --exclusive-threshold=10 drd/tests/hold_lock -i 500
@@ -721,17 +724,17 @@
</listitem>
<listitem>
<para>
- Attempt to unlock a mutex that has not been locked.
+ Attempts to unlock a mutex that has not been locked.
</para>
</listitem>
<listitem>
<para>
- Attempt to unlock a mutex that was locked by another thread.
+ Attempts to unlock a mutex that was locked by another thread.
</para>
</listitem>
<listitem>
<para>
- Attempt to lock a mutex of type
+ Attempts to lock a mutex of type
<literal>PTHREAD_MUTEX_NORMAL</literal> or a spinlock
recursively.
</para>
@@ -749,7 +752,7 @@
</listitem>
<listitem>
<para>
- Calling <function>pthread_cond_wait()</function> with a mutex
+ Calling <function>pthread_cond_wait()</function> on a mutex
that is not locked, that is locked by another thread or that
has been locked recursively.
</para>
@@ -757,7 +760,7 @@
<listitem>
<para>
Associating two different mutexes with a condition variable
- via <function>pthread_cond_wait()</function>.
+ through <function>pthread_cond_wait()</function>.
</para>
</listitem>
<listitem>
@@ -773,13 +776,13 @@
</listitem>
<listitem>
<para>
- Attempt to unlock a reader-writer lock that was not locked by
+ Attempts to unlock a reader-writer lock that was not locked by
the calling thread.
</para>
</listitem>
<listitem>
<para>
- Attempt to recursively lock a reader-writer lock exclusively.
+ Attempts to recursively lock a reader-writer lock exclusively.
</para>
</listitem>
<listitem>
@@ -804,16 +807,6 @@
</itemizedlist>
</para>
-<para>
-Regarding the message DRD prints about sending a signal to a condition
-variable while no lock is held on the mutex associated with the
-signal: DRD reports this because some calls of
-<function>pthread_cond_signal()</function> or
-<function>pthread_cond_broadcast()</function> while no lock is held on
-the mutex associated with the condition variable introduce subtle race
-conditions.
-</para>
-
</sect2>
@@ -882,7 +875,6 @@
<para>
<varname>VG_USERREQ__DRD_STOP_TRACE_ADDR</varname>. Do no longer
trace load and store activity for the specified address range.
- range.
</para>
</listitem>
</itemizedlist>
@@ -1073,7 +1065,7 @@
In the above output the function name <function>gj.omp_fn.0</function>
has been generated by gcc from the function name
<function>gj</function>. Unfortunately the variable name
-(<literal>k</literal>) is not shown as the allocation context -- it is
+<literal>k</literal> is not shown as the allocation context -- it is
not clear to me whether this is caused by Valgrind or whether this is
caused by gcc. The most usable information in the above output is the
source file name and the line number where the data race has been detected
@@ -1147,7 +1139,7 @@
<para>
It is essential for correct operation of DRD that there are no memory
-errors like dangling pointers in the client program. Which means that
+errors such as dangling pointers in the client program. Which means that
it is a good idea to make sure that your program is memcheck-clean
before you analyze it with DRD. It is possible however that some of
the memcheck reports are caused by data races. In this case it makes
@@ -1332,7 +1324,7 @@
<para>
A condition variable allows one thread to wake up one or more other
-threads. Condition variables are typically used to notify one or more
+threads. Condition variables are often used to notify one or more
threads about state changes of shared data. Unfortunately it is very
easy to introduce race conditions by using condition variables as the
only means of state information propagation. A better approach is to
@@ -1341,8 +1333,8 @@
mechanism. See also the source file
<computeroutput>drd/tests/monitor_example.cpp</computeroutput> for an
example of how to implement this concept in C++. The monitor concept
-used in this example is a well known concept in computer science --
-see also Wikipedia for more information about the <ulink
+used in this example is a well known and very useful concept -- see
+also Wikipedia for more information about the <ulink
url="http://en.wikipedia.org/wiki/Monitor_(synchronization)">monitor</ulink>
concept.
</para>
@@ -1372,9 +1364,7 @@
<literal>CLOCK_MONOTONIC</literal> instead of
<literal>CLOCK_REALTIME</literal>. You can do this via
<computeroutput>pthread_condattr_setclock(...,
- CLOCK_MONOTONIC)</computeroutput>. See also
- <computeroutput>drd/tests/monitor_example.cpp</computeroutput>
- for an example.
+ CLOCK_MONOTONIC)</computeroutput>.
</para>
</listitem>
<listitem>
@@ -1386,6 +1376,9 @@
</para>
</listitem>
</itemizedlist>
+See also
+<computeroutput>drd/tests/monitor_example.cpp</computeroutput> for an
+example.
</para>
</sect2>
@@ -1501,8 +1494,7 @@
If you have any comments, suggestions, feedback or bug reports about
DRD, feel free to either post a message on the Valgrind users mailing
list or to file a bug report. See also <ulink
-url="&vg-url;">&vg-url;</ulink> for more information about the
-Valgrind mailing lists or about how to file a bug report.
+url="&vg-url;">&vg-url;</ulink> for more information.
</para>
</sect1>
|
|
From: <sv...@va...> - 2009-01-02 11:07:25
|
Author: tom Date: 2009-01-02 11:07:18 +0000 (Fri, 02 Jan 2009) New Revision: 8891 Log: Add some more Intel cache configuration values needed for Atom processors. These come from sandpile.org as the current version of Intel's Application Note 485 doesn't have them yet. Modified: trunk/cachegrind/cg-amd64.c trunk/cachegrind/cg-x86.c Modified: trunk/cachegrind/cg-amd64.c =================================================================== --- trunk/cachegrind/cg-amd64.c 2009-01-02 11:03:55 UTC (rev 8890) +++ trunk/cachegrind/cg-amd64.c 2009-01-02 11:07:18 UTC (rev 8891) @@ -100,9 +100,11 @@ /* TLB info, ignore */ case 0x01: case 0x02: case 0x03: case 0x04: case 0x05: - case 0x50: case 0x51: case 0x52: case 0x56: case 0x57: + case 0x4f: case 0x50: case 0x51: case 0x52: + case 0x56: case 0x57: case 0x59: case 0x5b: case 0x5c: case 0x5d: - case 0xb0: case 0xb1: case 0xb3: case 0xb4: + case 0xb0: case 0xb1: + case 0xb3: case 0xb4: case 0xba: case 0xc0: break; case 0x06: *I1c = (cache_t) { 8, 4, 32 }; break; @@ -111,6 +113,12 @@ case 0x0a: *D1c = (cache_t) { 8, 2, 32 }; break; case 0x0c: *D1c = (cache_t) { 16, 4, 32 }; break; + case 0x0e: + /* Real D1 cache configuration is: + D1c = (cache_t) { 24, 6, 64 }; */ + VG_(message)(Vg_DebugMsg, "warning: 24Kb D1 cache detected, treating as 16Kb"); + *D1c = (cache_t) { 16, 4, 64 }; + break; case 0x2c: *D1c = (cache_t) { 32, 8, 64 }; break; /* IA-64 info -- panic! */ @@ -194,6 +202,9 @@ case 0x7d: *L2c = (cache_t) { 2048, 8, 64 }; L2_found = True; break; case 0x7e: *L2c = (cache_t) { 256, 8, 128 }; L2_found = True; break; + case 0x7f: *L2c = (cache_t) { 512, 2, 64 }; L2_found = True; break; + case 0x80: *L2c = (cache_t) { 512, 8, 64 }; L2_found = True; break; + case 0x81: *L2c = (cache_t) { 128, 8, 32 }; L2_found = True; break; case 0x82: *L2c = (cache_t) { 256, 8, 32 }; L2_found = True; break; case 0x83: *L2c = (cache_t) { 512, 8, 32 }; L2_found = True; break; Modified: trunk/cachegrind/cg-x86.c =================================================================== --- trunk/cachegrind/cg-x86.c 2009-01-02 11:03:55 UTC (rev 8890) +++ trunk/cachegrind/cg-x86.c 2009-01-02 11:07:18 UTC (rev 8891) @@ -100,9 +100,11 @@ /* TLB info, ignore */ case 0x01: case 0x02: case 0x03: case 0x04: case 0x05: - case 0x50: case 0x51: case 0x52: case 0x56: case 0x57: + case 0x4f: case 0x50: case 0x51: case 0x52: + case 0x56: case 0x57: case 0x59: case 0x5b: case 0x5c: case 0x5d: - case 0xb0: case 0xb1: case 0xb3: case 0xb4: + case 0xb0: case 0xb1: + case 0xb3: case 0xb4: case 0xba: case 0xc0: break; case 0x06: *I1c = (cache_t) { 8, 4, 32 }; break; @@ -111,6 +113,12 @@ case 0x0a: *D1c = (cache_t) { 8, 2, 32 }; break; case 0x0c: *D1c = (cache_t) { 16, 4, 32 }; break; + case 0x0e: + /* Real D1 cache configuration is: + D1c = (cache_t) { 24, 6, 64 }; */ + VG_(message)(Vg_DebugMsg, "warning: 24Kb D1 cache detected, treating as 16Kb"); + *D1c = (cache_t) { 16, 4, 64 }; + break; case 0x2c: *D1c = (cache_t) { 32, 8, 64 }; break; /* IA-64 info -- panic! */ @@ -194,6 +202,9 @@ case 0x7d: *L2c = (cache_t) { 2048, 8, 64 }; L2_found = True; break; case 0x7e: *L2c = (cache_t) { 256, 8, 128 }; L2_found = True; break; + case 0x7f: *L2c = (cache_t) { 512, 2, 64 }; L2_found = True; break; + case 0x80: *L2c = (cache_t) { 512, 8, 64 }; L2_found = True; break; + case 0x81: *L2c = (cache_t) { 128, 8, 32 }; L2_found = True; break; case 0x82: *L2c = (cache_t) { 256, 8, 32 }; L2_found = True; break; case 0x83: *L2c = (cache_t) { 512, 8, 32 }; L2_found = True; break; |
|
From: <sv...@va...> - 2009-01-02 11:04:03
|
Author: tom
Date: 2009-01-02 11:03:55 +0000 (Fri, 02 Jan 2009)
New Revision: 8890
Log:
Remove spurious newlines from messages.
Modified:
trunk/cachegrind/cg-amd64.c
trunk/cachegrind/cg-x86.c
Modified: trunk/cachegrind/cg-amd64.c
===================================================================
--- trunk/cachegrind/cg-amd64.c 2009-01-02 10:42:27 UTC (rev 8889)
+++ trunk/cachegrind/cg-amd64.c 2009-01-02 11:03:55 UTC (rev 8890)
@@ -144,21 +144,21 @@
case 0x48:
/* Real L2 cache configuration is:
*L2c = (cache_t) { 3072, 12, 64 }; L2_found = True; */
- VG_(message)(Vg_DebugMsg, "warning: 3Mb L2 cache detected, treating as 2Mb\n");
+ VG_(message)(Vg_DebugMsg, "warning: 3Mb L2 cache detected, treating as 2Mb");
*L2c = (cache_t) { 2048, 8, 64 }; L2_found = True;
break;
case 0x49:
if ((family == 15) && (model == 6))
/* On Xeon MP (family F, model 6), this is for L3 */
VG_(message)(Vg_DebugMsg,
- "warning: L3 cache detected but ignored\n");
+ "warning: L3 cache detected but ignored");
else
*L2c = (cache_t) { 4096, 16, 64 }; L2_found = True;
break;
case 0x4e:
/* Real L2 cache configuration is:
*L2c = (cache_t) { 6144, 24, 64 }; L2_found = True; */
- VG_(message)(Vg_DebugMsg, "warning: 6Mb L2 cache detected, treating as 4Mb\n");
+ VG_(message)(Vg_DebugMsg, "warning: 6Mb L2 cache detected, treating as 4Mb");
*L2c = (cache_t) { 4096, 16, 64 }; L2_found = True;
break;
@@ -304,7 +304,7 @@
vendor_id[12] = '\0';
if (0 == level) {
- VG_(message)(Vg_DebugMsg, "CPUID level is 0, early Pentium?\n");
+ VG_(message)(Vg_DebugMsg, "CPUID level is 0, early Pentium?");
return -1;
}
Modified: trunk/cachegrind/cg-x86.c
===================================================================
--- trunk/cachegrind/cg-x86.c 2009-01-02 10:42:27 UTC (rev 8889)
+++ trunk/cachegrind/cg-x86.c 2009-01-02 11:03:55 UTC (rev 8890)
@@ -144,21 +144,21 @@
case 0x48:
/* Real L2 cache configuration is:
*L2c = (cache_t) { 3072, 12, 64 }; L2_found = True; */
- VG_(message)(Vg_DebugMsg, "warning: 3Mb L2 cache detected, treating as 2Mb\n");
+ VG_(message)(Vg_DebugMsg, "warning: 3Mb L2 cache detected, treating as 2Mb");
*L2c = (cache_t) { 2048, 8, 64 }; L2_found = True;
break;
case 0x49:
if ((family == 15) && (model == 6))
/* On Xeon MP (family F, model 6), this is for L3 */
VG_(message)(Vg_DebugMsg,
- "warning: L3 cache detected but ignored\n");
+ "warning: L3 cache detected but ignored");
else
*L2c = (cache_t) { 4096, 16, 64 }; L2_found = True;
break;
case 0x4e:
/* Real L2 cache configuration is:
*L2c = (cache_t) { 6144, 24, 64 }; L2_found = True; */
- VG_(message)(Vg_DebugMsg, "warning: 6Mb L2 cache detected, treating as 4Mb\n");
+ VG_(message)(Vg_DebugMsg, "warning: 6Mb L2 cache detected, treating as 4Mb");
*L2c = (cache_t) { 4096, 16, 64 }; L2_found = True;
break;
@@ -304,7 +304,7 @@
vendor_id[12] = '\0';
if (0 == level) {
- VG_(message)(Vg_DebugMsg, "CPUID level is 0, early Pentium?\n");
+ VG_(message)(Vg_DebugMsg, "CPUID level is 0, early Pentium?");
return -1;
}
|
|
From: <sv...@va...> - 2009-01-02 10:42:40
|
Author: tom
Date: 2009-01-02 10:42:27 +0000 (Fri, 02 Jan 2009)
New Revision: 8889
Log:
Add some more Intel L2 and L3 cache configuration values.
Modified:
trunk/cachegrind/cg-amd64.c
trunk/cachegrind/cg-x86.c
Modified: trunk/cachegrind/cg-amd64.c
===================================================================
--- trunk/cachegrind/cg-amd64.c 2009-01-01 13:15:47 UTC (rev 8888)
+++ trunk/cachegrind/cg-amd64.c 2009-01-02 10:42:27 UTC (rev 8889)
@@ -119,7 +119,8 @@
case 0x90: case 0x96: case 0x9b:
VG_(tool_panic)("IA-64 cache detected?!");
- case 0x22: case 0x23: case 0x25: case 0x29: case 0x46: case 0x47:
+ case 0x22: case 0x23: case 0x25: case 0x29:
+ case 0x46: case 0x47: case 0x4a: case 0x4b: case 0x4c: case 0x4d:
VG_(message)(Vg_DebugMsg,
"warning: L3 cache detected but ignored");
break;
@@ -140,6 +141,12 @@
case 0x43: *L2c = (cache_t) { 512, 4, 32 }; L2_found = True; break;
case 0x44: *L2c = (cache_t) { 1024, 4, 32 }; L2_found = True; break;
case 0x45: *L2c = (cache_t) { 2048, 4, 32 }; L2_found = True; break;
+ case 0x48:
+ /* Real L2 cache configuration is:
+ *L2c = (cache_t) { 3072, 12, 64 }; L2_found = True; */
+ VG_(message)(Vg_DebugMsg, "warning: 3Mb L2 cache detected, treating as 2Mb\n");
+ *L2c = (cache_t) { 2048, 8, 64 }; L2_found = True;
+ break;
case 0x49:
if ((family == 15) && (model == 6))
/* On Xeon MP (family F, model 6), this is for L3 */
@@ -148,6 +155,12 @@
else
*L2c = (cache_t) { 4096, 16, 64 }; L2_found = True;
break;
+ case 0x4e:
+ /* Real L2 cache configuration is:
+ *L2c = (cache_t) { 6144, 24, 64 }; L2_found = True; */
+ VG_(message)(Vg_DebugMsg, "warning: 6Mb L2 cache detected, treating as 4Mb\n");
+ *L2c = (cache_t) { 4096, 16, 64 }; L2_found = True;
+ break;
/* These are sectored, whatever that means */
case 0x60: *D1c = (cache_t) { 16, 8, 64 }; break; /* sectored */
Modified: trunk/cachegrind/cg-x86.c
===================================================================
--- trunk/cachegrind/cg-x86.c 2009-01-01 13:15:47 UTC (rev 8888)
+++ trunk/cachegrind/cg-x86.c 2009-01-02 10:42:27 UTC (rev 8889)
@@ -119,7 +119,8 @@
case 0x90: case 0x96: case 0x9b:
VG_(tool_panic)("IA-64 cache detected?!");
- case 0x22: case 0x23: case 0x25: case 0x29: case 0x46: case 0x47:
+ case 0x22: case 0x23: case 0x25: case 0x29:
+ case 0x46: case 0x47: case 0x4a: case 0x4b: case 0x4c: case 0x4d:
VG_(message)(Vg_DebugMsg,
"warning: L3 cache detected but ignored");
break;
@@ -140,6 +141,12 @@
case 0x43: *L2c = (cache_t) { 512, 4, 32 }; L2_found = True; break;
case 0x44: *L2c = (cache_t) { 1024, 4, 32 }; L2_found = True; break;
case 0x45: *L2c = (cache_t) { 2048, 4, 32 }; L2_found = True; break;
+ case 0x48:
+ /* Real L2 cache configuration is:
+ *L2c = (cache_t) { 3072, 12, 64 }; L2_found = True; */
+ VG_(message)(Vg_DebugMsg, "warning: 3Mb L2 cache detected, treating as 2Mb\n");
+ *L2c = (cache_t) { 2048, 8, 64 }; L2_found = True;
+ break;
case 0x49:
if ((family == 15) && (model == 6))
/* On Xeon MP (family F, model 6), this is for L3 */
@@ -148,6 +155,12 @@
else
*L2c = (cache_t) { 4096, 16, 64 }; L2_found = True;
break;
+ case 0x4e:
+ /* Real L2 cache configuration is:
+ *L2c = (cache_t) { 6144, 24, 64 }; L2_found = True; */
+ VG_(message)(Vg_DebugMsg, "warning: 6Mb L2 cache detected, treating as 4Mb\n");
+ *L2c = (cache_t) { 4096, 16, 64 }; L2_found = True;
+ break;
/* These are sectored, whatever that means */
case 0x60: *D1c = (cache_t) { 16, 8, 64 }; break; /* sectored */
|
|
From: Tom H. <to...@co...> - 2009-01-02 09:47:34
|
Josef Weidendorfer wrote: > Hmm... what does go wrong with these 8 tests? Is this something about > the cpuid check? Yep: warning: Unknown Intel cache config value (0x4e), ignoring warning: L2 cache not installed, ignore L2 results. The CPU is: Intel(R) Core(TM)2 Quad CPU Q9450 @ 2.66GHz It has a 6Mb cache, which is a problem I think as valgrind can only do powers of two can't it? Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: Tom H. <th...@cy...> - 2009-01-02 03:47:55
|
Nightly build on vauxhall ( x86_64, Fedora 10 ) started at 2009-01-02 03:20:06 GMT 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 == 481 tests, 13 stderr failures, 0 stdout failures, 0 post failures == cachegrind/tests/chdir (stderr) cachegrind/tests/clreq (stderr) cachegrind/tests/dlclose (stderr) cachegrind/tests/wrap5 (stderr) cachegrind/tests/x86/fpu-28-108 (stderr) callgrind/tests/simwork1 (stderr) callgrind/tests/simwork2 (stderr) callgrind/tests/simwork3 (stderr) exp-ptrcheck/tests/base (stderr) exp-ptrcheck/tests/preen_invars (stderr) memcheck/tests/linux-syscalls-2007 (stderr) memcheck/tests/x86/scalar (stderr) none/tests/blockfault (stderr) |
|
From: Tom H. <th...@cy...> - 2009-01-02 03:47:36
|
Nightly build on trojan ( x86_64, Fedora Core 6 ) started at 2009-01-02 03:25:04 GMT 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 == 476 tests, 8 stderr failures, 4 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/tc20_verifywrap (stderr) 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...> - 2009-01-02 03:36:45
|
Nightly build on mg ( x86_64, Fedora 9 ) started at 2009-01-02 03:10:07 GMT 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 == 478 tests, 14 stderr failures, 2 stdout failures, 0 post failures == cachegrind/tests/chdir (stderr) cachegrind/tests/clreq (stderr) cachegrind/tests/dlclose (stderr) cachegrind/tests/wrap5 (stderr) cachegrind/tests/x86/fpu-28-108 (stderr) callgrind/tests/simwork1 (stderr) callgrind/tests/simwork2 (stderr) callgrind/tests/simwork3 (stderr) exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) memcheck/tests/linux-timerfd-syscall (stdout) memcheck/tests/x86/scalar (stderr) none/tests/blockfault (stderr) none/tests/mremap2 (stdout) |