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-03 22:46:22
|
Author: njn Date: 2009-01-03 22:46:15 +0000 (Sat, 03 Jan 2009) New Revision: 8907 Log: Very minor changes. Modified: branches/VCOV/exp-vcov/docs/vc-manual.xml branches/VCOV/exp-vcov/vc_main.c Modified: branches/VCOV/exp-vcov/docs/vc-manual.xml =================================================================== --- branches/VCOV/exp-vcov/docs/vc-manual.xml 2009-01-03 20:32:55 UTC (rev 8906) +++ branches/VCOV/exp-vcov/docs/vc-manual.xml 2009-01-03 22:46:15 UTC (rev 8907) @@ -27,6 +27,9 @@ <listitem> <para>Stuff about debug info, compiling without optimisation</para> + Nb: using -fprofile-arcs apparently gives misleading results -- eg. + suggests that lines that aren't executed actually are. Don't use it with + VCov. </listitem> <listitem> Modified: branches/VCOV/exp-vcov/vc_main.c =================================================================== --- branches/VCOV/exp-vcov/vc_main.c 2009-01-03 20:32:55 UTC (rev 8906) +++ branches/VCOV/exp-vcov/vc_main.c 2009-01-03 22:46:15 UTC (rev 8907) @@ -34,6 +34,8 @@ // - the new seginfo_* functions -- would providing an iterator be better? // - write tests -- work out how to make them deterministic... // - write docs +// - add a first line to the output indicating it's VCov and the output +// version number. Eg. "vcov 1" // Overview: // - VCov is a coverage testing tool. It has similarities and differences |
|
From: <sv...@va...> - 2009-01-03 21:06:02
|
Author: sewardj Date: 2009-01-03 21:05:55 +0000 (Sat, 03 Jan 2009) New Revision: 373 Log: Update for 3.4.0. Modified: trunk/docs/manual/valgrind_manual.html.tar.bz2 Modified: trunk/docs/manual/valgrind_manual.html.tar.bz2 =================================================================== (Binary files differ) |
|
From: <sv...@va...> - 2009-01-03 20:49:08
|
Author: sewardj Date: 2009-01-03 20:48:56 +0000 (Sat, 03 Jan 2009) New Revision: 372 Log: Update the online manual for 3.4.0. Modified: trunk/docs/manual/FAQ.html trunk/docs/manual/QuickStart.html trunk/docs/manual/cg-manual.html trunk/docs/manual/cl-manual.html trunk/docs/manual/dist.html trunk/docs/manual/dist.readme-missing.html trunk/docs/manual/dist.readme-packagers.html trunk/docs/manual/faq.html trunk/docs/manual/hg-manual.html trunk/docs/manual/index.html trunk/docs/manual/lk-manual.html trunk/docs/manual/manual-core.html trunk/docs/manual/manual.html trunk/docs/manual/mc-manual.html trunk/docs/manual/ms-manual.html trunk/docs/manual/nl-manual.html trunk/docs/manual/quick-start.html trunk/docs/manual/tech-docs.html trunk/docs/manual/valgrind_manual.pdf trunk/docs/manual/valgrind_manual.ps.bz2 [... diff too large to include ...] |
|
From: <sv...@va...> - 2009-01-03 20:46:25
|
Author: sewardj Date: 2009-01-03 20:46:17 +0000 (Sat, 03 Jan 2009) New Revision: 371 Log: Add new (and missing) manual pieces. Added: trunk/docs/manual/drd-manual.html trunk/docs/manual/pc-manual.html trunk/docs/manual/vg_basic.css Added: trunk/docs/manual/drd-manual.html =================================================================== --- trunk/docs/manual/drd-manual.html (rev 0) +++ trunk/docs/manual/drd-manual.html 2009-01-03 20:46:17 UTC (rev 371) @@ -0,0 +1,1273 @@ +<html> +<head> +<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> +<title>8.DRD: a thread error detector</title> +<link rel="stylesheet" href="vg_basic.css" type="text/css"> +<meta name="generator" content="DocBook XSL Stylesheets V1.69.1"> +<link rel="start" href="index.html" title="Valgrind Documentation"> +<link rel="up" href="manual.html" title="Valgrind User Manual"> +<link rel="prev" href="hg-manual.html" title="7.Helgrind: a thread error detector"> +<link rel="next" href="ms-manual.html" title="9.Massif: a heap profiler"> +</head> +<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"> +<div><table class="nav" width="100%" cellspacing="3" cellpadding="3" border="0" summary="Navigation header"><tr> +<td width="22px" align="center" valign="middle"><a accesskey="p" href="hg-manual.html"><img src="images/prev.png" width="18" height="21" border="0" alt="Prev"></a></td> +<td width="25px" align="center" valign="middle"><a accesskey="u" href="manual.html"><img src="images/up.png" width="21" height="18" border="0" alt="Up"></a></td> +<td width="31px" align="center" valign="middle"><a accesskey="h" href="index.html"><img src="images/home.png" width="27" height="20" border="0" alt="Up"></a></td> +<th align="center" valign="middle">Valgrind User Manual</th> +<td width="22px" align="center" valign="middle"><a accesskey="n" href="ms-manual.html"><img src="images/next.png" width="18" height="21" border="0" alt="Next"></a></td> +</tr></table></div> +<div class="chapter" lang="en"> +<div class="titlepage"><div><div><h2 class="title"> +<a name="drd-manual"></a>8.DRD: a thread error detector</h2></div></div></div> +<div class="toc"> +<p><b>Table of Contents</b></p> +<dl> +<dt><span class="sect1"><a href="drd-manual.html#drd-manual.overview">8.1. Background</a></span></dt> +<dd><dl> +<dt><span class="sect2"><a href="drd-manual.html#drd-manual.mt-progr-models">8.1.1. Multithreaded Programming Paradigms</a></span></dt> +<dt><span class="sect2"><a href="drd-manual.html#drd-manual.pthreads-model">8.1.2. POSIX Threads Programming Model</a></span></dt> +<dt><span class="sect2"><a href="drd-manual.html#drd-manual.mt-problems">8.1.3. Multithreaded Programming Problems</a></span></dt> +<dt><span class="sect2"><a href="drd-manual.html#drd-manual.data-race-detection">8.1.4. Data Race Detection</a></span></dt> +</dl></dd> +<dt><span class="sect1"><a href="drd-manual.html#drd-manual.using-drd">8.2. Using DRD</a></span></dt> +<dd><dl> +<dt><span class="sect2"><a href="drd-manual.html#drd-manual.options">8.2.1. Command Line Options</a></span></dt> +<dt><span class="sect2"><a href="drd-manual.html#drd-manual.data-races">8.2.2. Detected Errors: Data Races</a></span></dt> +<dt><span class="sect2"><a href="drd-manual.html#drd-manual.lock-contention">8.2.3. Detected Errors: Lock Contention</a></span></dt> +<dt><span class="sect2"><a href="drd-manual.html#drd-manual.api-checks">8.2.4. Detected Errors: Misuse of the POSIX threads API</a></span></dt> +<dt><span class="sect2"><a href="drd-manual.html#drd-manual.clientreqs">8.2.5. Client Requests</a></span></dt> +<dt><span class="sect2"><a href="drd-manual.html#drd-manual.gnome">8.2.6. Debugging GNOME Programs</a></span></dt> +<dt><span class="sect2"><a href="drd-manual.html#drd-manual.qt">8.2.7. Debugging Qt Programs</a></span></dt> +<dt><span class="sect2"><a href="drd-manual.html#drd-manual.boost.thread">8.2.8. Debugging Boost.Thread Programs</a></span></dt> +<dt><span class="sect2"><a href="drd-manual.html#drd-manual.openmp">8.2.9. Debugging OpenMP Programs</a></span></dt> +<dt><span class="sect2"><a href="drd-manual.html#drd-manual.cust-mem-alloc">8.2.10. DRD and Custom Memory Allocators</a></span></dt> +<dt><span class="sect2"><a href="drd-manual.html#drd-manual.drd-versus-memcheck">8.2.11. DRD Versus Memcheck</a></span></dt> +<dt><span class="sect2"><a href="drd-manual.html#drd-manual.resource-requirements">8.2.12. Resource Requirements</a></span></dt> +<dt><span class="sect2"><a href="drd-manual.html#drd-manual.effective-use">8.2.13. Hints and Tips for Effective Use of DRD</a></span></dt> +</dl></dd> +<dt><span class="sect1"><a href="drd-manual.html#drd-manual.Pthreads">8.3. Using the POSIX Threads API Effectively</a></span></dt> +<dd><dl> +<dt><span class="sect2"><a href="drd-manual.html#drd-manual.mutex-types">8.3.1. Mutex types</a></span></dt> +<dt><span class="sect2"><a href="drd-manual.html#drd-manual.condvar">8.3.2. Condition variables</a></span></dt> +<dt><span class="sect2"><a href="drd-manual.html#drd-manual.pctw">8.3.3. pthread_cond_timedwait() and timeouts</a></span></dt> +<dt><span class="sect2"><a href="drd-manual.html#drd-manual.naming-threads">8.3.4. Assigning names to threads</a></span></dt> +</dl></dd> +<dt><span class="sect1"><a href="drd-manual.html#drd-manual.limitations">8.4. Limitations</a></span></dt> +<dt><span class="sect1"><a href="drd-manual.html#drd-manual.feedback">8.5. Feedback</a></span></dt> +</dl> +</div> +<p>To use this tool, you must specify +<code class="computeroutput">--tool=drd</code> +on the Valgrind command line.</p> +<div class="sect1" lang="en"> +<div class="titlepage"><div><div><h2 class="title" style="clear: both"> +<a name="drd-manual.overview"></a>8.1.Background</h2></div></div></div> +<p> +DRD is a Valgrind tool for detecting errors in multithreaded C and C++ +shared-memory programs. The tool works for any program that uses the +POSIX threading primitives or that uses threading concepts built on +top of the POSIX threading primitives. +</p> +<div class="sect2" lang="en"> +<div class="titlepage"><div><div><h3 class="title"> +<a name="drd-manual.mt-progr-models"></a>8.1.1.Multithreaded Programming Paradigms</h3></div></div></div> +<p> +For many applications multithreading is a necessity. There are two +reasons why the use of threads may be required: +</p> +<div class="itemizedlist"><ul type="disc"> +<li><p> + To model concurrent activities. Managing the state of one + activity per thread can be a great simplification compared to + multiplexing the states of multiple activities in a single + thread. This is why most server and embedded software is + multithreaded. + </p></li> +<li><p> + To let computations run on multiple CPU cores + simultaneously. This is why many High Performance Computing + (HPC) applications are multithreaded. + </p></li> +</ul></div> +<p> +</p> +<p> +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: +</p> +<div class="itemizedlist"><ul type="disc"> +<li><p> + Locking. Data that is shared between threads may only be + 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. + </p></li> +<li><p> + Message passing. No data is shared between threads, but threads + exchange data by passing messages to each other. Well known + implementations of the message passing paradigm are MPI and + CORBA. + </p></li> +<li><p> + 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, + <code class="computeroutput">gcc</code> 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. + </p></li> +<li><p> + 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 + transactions. If there were conflicts, the transaction is + aborted, otherwise it is committed. This is a so-called + optimistic approach. There is a prototype of the Intel C + Compiler (<code class="computeroutput">icc</code>) available that + supports STM. Research is ongoing about the addition of STM + support to <code class="computeroutput">gcc</code>. + </p></li> +</ul></div> +<p> +</p> +<p> +DRD supports any combination of multithreaded programming paradigms as +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 cause DRD to report many false positives. +</p> +</div> +<div class="sect2" lang="en"> +<div class="titlepage"><div><div><h3 class="title"> +<a name="drd-manual.pthreads-model"></a>8.1.2.POSIX Threads Programming Model</h3></div></div></div> +<p> +POSIX threads, also known as Pthreads, is the most widely available +threading library on Unix systems. +</p> +<p> +The POSIX threads programming model is based on the following abstractions: +</p> +<div class="itemizedlist"><ul type="disc"> +<li><p> + A shared address space. All threads running within the same + process share the same address space. All data, whether shared or + not, is identified by its address. + </p></li> +<li><p> + Regular load and store operations, which allow to read values + from or to write values to the memory shared by all threads + running in the same process. + </p></li> +<li><p> + 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. <code class="computeroutput">__sync_fetch_and_add()</code> + which is supported by both <code class="computeroutput">gcc</code> + and <code class="computeroutput">icc</code>. + </p></li> +<li><p> + Threads. Each thread represents a concurrent activity. + </p></li> +<li><p> + Synchronization objects and operations on these synchronization + objects. The following types of synchronization objects are + defined in the POSIX threads standard: mutexes, condition + variables, semaphores, reader-writer locks, barriers and + spinlocks. + </p></li> +</ul></div> +<p> +</p> +<p> +Which source code statements generate which memory accesses depends on +the <span class="emphasis"><em>memory model</em></span> 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 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2338.html" target="_top"> +WG21/N2338</a>. +</p> +<p> +For more information about POSIX threads, see also the Single UNIX +Specification version 3, also known as +<a href="http://www.unix.org/version3/ieee_std.html" target="_top"> +IEEE Std 1003.1</a>. +</p> +</div> +<div class="sect2" lang="en"> +<div class="titlepage"><div><div><h3 class="title"> +<a name="drd-manual.mt-problems"></a>8.1.3.Multithreaded Programming Problems</h3></div></div></div> +<p> +Depending on which multithreading paradigm is being used in a program, +one or more of the following problems can occur: +</p> +<div class="itemizedlist"><ul type="disc"> +<li><p> + Data races. One or more threads access the same memory + location without sufficient locking. + </p></li> +<li><p> + Lock contention. One thread blocks the progress of one or more other + threads by holding a lock too long. + </p></li> +<li><p> + Improper use of the POSIX threads API. The most popular POSIX + threads implementation, NPTL, is optimized for speed. The NPTL + will not complain on certain errors, e.g. when a mutex is locked + in one thread and unlocked in another thread. + </p></li> +<li><p> + Deadlock. A deadlock occurs when two or more threads wait for + each other indefinitely. + </p></li> +<li><p> + False sharing. If threads that run on different processor cores + access different variables located in the same cache line + frequently, this will slow down the involved threads a lot due + to frequent exchange of cache lines. + </p></li> +</ul></div> +<p> +</p> +<p> +Although the likelihood of the occurrence of data races can be reduced +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. +</p> +</div> +<div class="sect2" lang="en"> +<div class="titlepage"><div><div><h3 class="title"> +<a name="drd-manual.data-race-detection"></a>8.1.4.Data Race Detection</h3></div></div></div> +<p> +Synchronization operations impose an order on interthread memory +accesses. This order is also known as the happens-before relationship. +</p> +<p> +A multithreaded program is data-race free if all interthread memory +accesses are ordered by synchronization operations. +</p> +<p> +A well known way to ensure that a multithreaded program is data-race +free is to ensure that a locking discipline is followed. It is e.g. +possible to associate a mutex with each shared data item, and to hold +a lock on the associated mutex while the shared data is accessed. +</p> +<p> +All programs that follow a locking discipline are data-race free, but +not all data-race free programs follow a locking discipline. There +exist multithreaded programs where access to shared data is arbitrated +via condition variables, semaphores or barriers. As an example, a +certain class of HPC applications consists of a sequence of +computation steps separated in time by barriers, and where these +barriers are the only means of synchronization. +</p> +<p> +There exist two different algorithms for verifying the correctness of +multithreaded programs at runtime. The so-called Eraser algorithm +verifies whether all shared memory accesses follow a consistent +locking strategy. And the happens-before data race detectors verify +directly whether all interthread memory accesses are ordered by +synchronization operations. While the happens-before data race +detection algorithm is more complex to implement, and while it is more +sensitive to OS scheduling, it is a general approach that works for +all classes of multithreaded programs. Furthermore, the happens-before +data race detection algorithm does not report any false positives. +</p> +<p> +DRD is based on the happens-before algorithm. +</p> +</div> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"><div><div><h2 class="title" style="clear: both"> +<a name="drd-manual.using-drd"></a>8.2.Using DRD</h2></div></div></div> +<div class="sect2" lang="en"> +<div class="titlepage"><div><div><h3 class="title"> +<a name="drd-manual.options"></a>8.2.1.Command Line Options</h3></div></div></div> +<p>The following command-line options are available for controlling the +behavior of the DRD tool itself:</p> +<div class="variablelist"> +<a name="drd.opts.list"></a><dl> +<dt><span class="term"> + <code class="option">--check-stack-var=<yes|no> [default: no]</code> + </span></dt> +<dd><p> + Controls whether <code class="constant">DRD</code> reports data races + for stack variables. This is disabled by default in order to + accelerate data race detection. Most programs do not share + stack variables over threads. + </p></dd> +<dt><span class="term"> + <code class="option">--exclusive-threshold=<n> [default: off]</code> + </span></dt> +<dd><p> + 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. + </p></dd> +<dt><span class="term"> + <code class="option"> + --report-signal-unlocked=<yes|no> [default: yes] + </code> + </span></dt> +<dd><p> + Whether to report calls to + <code class="function">pthread_cond_signal()</code> and + <code class="function">pthread_cond_broadcast()</code> where the mutex + associated with the signal through + <code class="function">pthread_cond_wait()</code> or + <code class="function">pthread_cond_timed_wait()</code>is not locked at + the time the signal is sent. Sending a signal without holding + a lock on the associated mutex is a common programming error + which can cause subtle race conditions and unpredictable + behavior. There exist some uncommon synchronization patterns + however where it is safe to send a signal without holding a + lock on the associated mutex. + </p></dd> +<dt><span class="term"> + <code class="option">--segment-merging=<yes|no> [default: yes]</code> + </span></dt> +<dd><p> + Controls segment merging. Segment merging is an algorithm to + limit memory usage of the data race detection + algorithm. Disabling segment merging may improve the accuracy + of the so-called 'other segments' displayed in race reports + but can also trigger an out of memory error. + </p></dd> +<dt><span class="term"> + <code class="option">--shared-threshold=<n> [default: off]</code> + </span></dt> +<dd><p> + 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. + </p></dd> +<dt><span class="term"> + <code class="option">--show-confl-seg=<yes|no> [default: yes]</code> + </span></dt> +<dd><p> + Show conflicting segments in race reports. Since this + information can help to find the cause of a data race, this + option is enabled by default. Disabling this option makes the + output of DRD more compact. + </p></dd> +<dt><span class="term"> + <code class="option">--show-stack-usage=<yes|no> [default: no]</code> + </span></dt> +<dd><p> + 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. + </p></dd> +<dt><span class="term"> + <code class="option">--var-info=<yes|no> [default: no]</code> + </span></dt> +<dd><p> + Display the names of global, static and stack variables when a + data race is reported. While this information can be very + 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. + </p></dd> +</dl> +</div> +<p> +The following options are available for monitoring the behavior of the +client program: +</p> +<div class="variablelist"> +<a name="drd.debugopts.list"></a><dl> +<dt><span class="term"> + <code class="option">--trace-addr=<address> [default: none]</code> + </span></dt> +<dd><p> + Trace all load and store activity for the specified + address. This option may be specified more than once. + </p></dd> +<dt><span class="term"> + <code class="option">--trace-barrier=<yes|no> [default: no]</code> + </span></dt> +<dd><p> + Trace all barrier activity. + </p></dd> +<dt><span class="term"> + <code class="option">--trace-cond=<yes|no> [default: no]</code> + </span></dt> +<dd><p> + Trace all condition variable activity. + </p></dd> +<dt><span class="term"> + <code class="option">--trace-fork-join=<yes|no> [default: no]</code> + </span></dt> +<dd><p> + Trace all thread creation and all thread termination events. + </p></dd> +<dt><span class="term"> + <code class="option">--trace-mutex=<yes|no> [default: no]</code> + </span></dt> +<dd><p> + Trace all mutex activity. + </p></dd> +<dt><span class="term"> + <code class="option">--trace-rwlock=<yes|no> [default: no]</code> + </span></dt> +<dd><p> + Trace all reader-writer lock activity. + </p></dd> +<dt><span class="term"> + <code class="option">--trace-semaphore=<yes|no> [default: no]</code> + </span></dt> +<dd><p> + Trace all semaphore activity. + </p></dd> +</dl> +</div> +</div> +<div class="sect2" lang="en"> +<div class="titlepage"><div><div><h3 class="title"> +<a name="drd-manual.data-races"></a>8.2.2.Detected Errors: Data Races</h3></div></div></div> +<p> +DRD prints a message every time it detects a data race. Please keep +the following in mind when interpreting DRD's output: +</p> +<div class="itemizedlist"><ul type="disc"> +<li><p> + Every thread is assigned two <span class="emphasis"><em>thread ID's</em></span>: + one thread ID is assigned by the Valgrind core and one thread ID + is assigned by DRD. Both thread ID's start at one. Valgrind + thread ID's are reused when one thread finishes and another + thread is created. DRD does not reuse thread ID's. Thread ID's + are displayed e.g. as follows: 2/3, where the first number is + Valgrind's thread ID and the second number is the thread ID + assigned by DRD. + </p></li> +<li><p> + The term <span class="emphasis"><em>segment</em></span> refers to a consecutive + sequence of load, store and synchronization operations, all + issued by the same thread. A segment always starts and ends at a + synchronization operation. Data race analysis is performed + between segments instead of between individual load and store + operations because of performance reasons. + </p></li> +<li><p> + There are always at least two memory accesses involved in a data + race. Memory accesses involved in a data race are called + <span class="emphasis"><em>conflicting memory accesses</em></span>. DRD prints a + report for each memory access that conflicts with a past memory + access. + </p></li> +</ul></div> +<p> +</p> +<p> +Below you can find an example of a message printed by DRD when it +detects a data race: +</p> +<pre class="programlisting"> +$ valgrind --tool=drd --var-info=yes drd/tests/rwlock_race +... +==9466== Thread 3: +==9466== Conflicting load by thread 3/3 at 0x006020b8 size 4 +==9466== at 0x400B6C: thread_func (rwlock_race.c:29) +==9466== by 0x4C291DF: vg_thread_wrapper (drd_pthread_intercepts.c:186) +==9466== by 0x4E3403F: start_thread (in /lib64/libpthread-2.8.so) +==9466== by 0x53250CC: clone (in /lib64/libc-2.8.so) +==9466== Location 0x6020b8 is 0 bytes inside local var "s_racy" +==9466== declared at rwlock_race.c:18, in frame #0 of thread 3 +==9466== Other segment start (thread 2/2) +==9466== at 0x4C2847D: pthread_rwlock_rdlock* (drd_pthread_intercepts.c:813) +==9466== by 0x400B6B: thread_func (rwlock_race.c:28) +==9466== by 0x4C291DF: vg_thread_wrapper (drd_pthread_intercepts.c:186) +==9466== by 0x4E3403F: start_thread (in /lib64/libpthread-2.8.so) +==9466== by 0x53250CC: clone (in /lib64/libc-2.8.so) +==9466== Other segment end (thread 2/2) +==9466== at 0x4C28B54: pthread_rwlock_unlock* (drd_pthread_intercepts.c:912) +==9466== by 0x400B84: thread_func (rwlock_race.c:30) +==9466== by 0x4C291DF: vg_thread_wrapper (drd_pthread_intercepts.c:186) +==9466== by 0x4E3403F: start_thread (in /lib64/libpthread-2.8.so) +==9466== by 0x53250CC: clone (in /lib64/libc-2.8.so) +... +</pre> +<p> +The above report has the following meaning: +</p> +<div class="itemizedlist"><ul type="disc"> +<li><p> + The number in the column on the left is the process ID of the + process being analyzed by DRD. + </p></li> +<li><p> + The first line ("Thread 3") tells you Valgrind's thread ID for + the thread in which context the data race was detected. + </p></li> +<li><p> + The next line tells which kind of operation was performed (load + or store) and by which thread. Both Valgrind's and DRD's thread + ID's are displayed. On the same line the start address and the + number of bytes involved in the conflicting access are also + displayed. + </p></li> +<li><p> + Next, the call stack of the conflicting access is displayed. If + 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 (<code class="function">clone</code> + and <code class="function">start_thread</code>) show how the NPTL starts + a thread. The third frame + (<code class="function">vg_thread_wrapper</code>) is added by DRD. The + fourth frame (<code class="function">thread_func</code>) 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 + <code class="function">pthread_create()</code>. + </p></li> +<li><p> + Next, the allocation context for the conflicting address is + 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 + <code class="computeroutput">--var-info=yes</code> has been + specified. Otherwise DRD will print <code class="computeroutput">Allocation + context: unknown</code>. + </p></li> +<li> +<p> + A conflicting access involves at least two memory accesses. For + one of these accesses an exact call stack is displayed, and for + the other accesses an approximate call stack is displayed, + namely the start and the end of the segments of the other + accesses. This information can be interpreted as follows: + </p> +<div class="orderedlist"><ol type="1"> +<li><p> + Start at the bottom of both call stacks, and count the + number stack frames with identical function name, file + name and line number. In the above example the three + bottommost frames are identical + (<code class="function">clone</code>, + <code class="function">start_thread</code> and + <code class="function">vg_thread_wrapper</code>). + </p></li> +<li><p> + The next higher stack frame in both call stacks now tells + you between in which source code region the other memory + access happened. The above output tells that the other + memory access involved in the data race happened between + source code lines 28 and 30 in file + <code class="computeroutput">rwlock_race.c</code>. + </p></li> +</ol></div> +<p> + </p> +</li> +</ul></div> +<p> +</p> +</div> +<div class="sect2" lang="en"> +<div class="titlepage"><div><div><h3 class="title"> +<a name="drd-manual.lock-contention"></a>8.2.3.Detected Errors: Lock Contention</h3></div></div></div> +<p> +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 +<span class="emphasis"><em>lock contention</em></span>. +</p> +<p> +Lock contention causes delays. Such delays should be as short as +possible. The two command line options +<code class="literal">--exclusive-threshold=<n></code> and +<code class="literal">--shared-threshold=<n></code> make it possible to +detect excessive lock contention by making DRD report any lock that +has been held longer than the specified threshold. An example: +</p> +<pre class="programlisting"> +$ valgrind --tool=drd --exclusive-threshold=10 drd/tests/hold_lock -i 500 +... +==10668== Acquired at: +==10668== at 0x4C267C8: pthread_mutex_lock (drd_pthread_intercepts.c:395) +==10668== by 0x400D92: main (hold_lock.c:51) +==10668== Lock on mutex 0x7fefffd50 was held during 503 ms (threshold: 10 ms). +==10668== at 0x4C26ADA: pthread_mutex_unlock (drd_pthread_intercepts.c:441) +==10668== by 0x400DB5: main (hold_lock.c:55) +... +</pre> +<p> +The <code class="literal">hold_lock</code> test program holds a lock as long as +specified by the <code class="literal">-i</code> (interval) argument. The DRD +output reports that the lock acquired at line 51 in source file +<code class="literal">hold_lock.c</code> and released at line 55 was held during +503 ms, while a threshold of 10 ms was specified to DRD. +</p> +</div> +<div class="sect2" lang="en"> +<div class="titlepage"><div><div><h3 class="title"> +<a name="drd-manual.api-checks"></a>8.2.4.Detected Errors: Misuse of the POSIX threads API</h3></div></div></div> +<p> + DRD is able to detect and report the following misuses of the POSIX + threads API: + </p> +<div class="itemizedlist"><ul type="disc"> +<li><p> + Passing the address of one type of synchronization object + (e.g. a mutex) to a POSIX API call that expects a pointer to + another type of synchronization object (e.g. a condition + variable). + </p></li> +<li><p> + Attempts to unlock a mutex that has not been locked. + </p></li> +<li><p> + Attempts to unlock a mutex that was locked by another thread. + </p></li> +<li><p> + Attempts to lock a mutex of type + <code class="literal">PTHREAD_MUTEX_NORMAL</code> or a spinlock + recursively. + </p></li> +<li><p> + Destruction or deallocation of a locked mutex. + </p></li> +<li><p> + Sending a signal to a condition variable while no lock is held + on the mutex associated with the signal. + </p></li> +<li><p> + Calling <code class="function">pthread_cond_wait()</code> on a mutex + that is not locked, that is locked by another thread or that + has been locked recursively. + </p></li> +<li><p> + Associating two different mutexes with a condition variable + through <code class="function">pthread_cond_wait()</code>. + </p></li> +<li><p> + Destruction or deallocation of a condition variable that is + being waited upon. + </p></li> +<li><p> + Destruction or deallocation of a locked reader-writer lock. + </p></li> +<li><p> + Attempts to unlock a reader-writer lock that was not locked by + the calling thread. + </p></li> +<li><p> + Attempts to recursively lock a reader-writer lock exclusively. + </p></li> +<li><p> + Reinitialization of a mutex, condition variable, reader-writer + lock, semaphore or barrier. + </p></li> +<li><p> + Destruction or deallocation of a semaphore or barrier that is + being waited upon. + </p></li> +<li><p> + Exiting a thread without first unlocking the spinlocks, + mutexes or reader-writer locks that were locked by that + thread. + </p></li> +</ul></div> +<p> +</p> +</div> +<div class="sect2" lang="en"> +<div class="titlepage"><div><div><h3 class="title"> +<a name="drd-manual.clientreqs"></a>8.2.5.Client Requests</h3></div></div></div> +<p> +Just as for other Valgrind tools it is possible to let a client +program interact with the DRD tool. +</p> +<p> +The interface between client programs and the DRD tool is defined in +the header file <code class="literal"><valgrind/drd.h></code>. The +available client requests are: +</p> +<div class="itemizedlist"><ul type="disc"> +<li><p> + <code class="varname">VG_USERREQ__DRD_GET_VALGRIND_THREAD_ID</code>. + Query the thread ID that was assigned by the Valgrind core to + the thread executing this client request. Valgrind's thread ID's + start at one and are recycled in case a thread stops. + </p></li> +<li><p> + <code class="varname">VG_USERREQ__DRD_GET_DRD_THREAD_ID</code>. + Query the thread ID that was assigned by DRD to + the thread executing this client request. DRD's thread ID's + start at one and are never recycled. + </p></li> +<li><p> + <code class="varname">VG_USERREQ__DRD_START_SUPPRESSION</code>. Some + applications contain intentional races. There exist + e.g. applications where the same value is assigned to a shared + variable from two different threads. It may be more convenient + to suppress such races than to solve these. This client request + allows to suppress such races. See also the macro + <code class="literal">DRD_IGNORE_VAR(x)</code> defined in + <code class="literal"><valgrind/drd.h></code>. + </p></li> +<li><p> + <code class="varname">VG_USERREQ__DRD_FINISH_SUPPRESSION</code>. Tell DRD + to no longer ignore data races in the address range that was + suppressed via + <code class="varname">VG_USERREQ__DRD_START_SUPPRESSION</code>. + </p></li> +<li><p> + <code class="varname">VG_USERREQ__DRD_START_TRACE_ADDR</code>. Trace all + load and store activity on the specified address range. When DRD + reports a data race on a specified variable, and it's not + immediately clear which source code statements triggered the + conflicting accesses, it can be helpful to trace all activity on + the offending memory location. See also the macro + <code class="literal">DRD_TRACE_VAR(x)</code> defined in + <code class="literal"><valgrind/drd.h></code>. + </p></li> +<li><p> + <code class="varname">VG_USERREQ__DRD_STOP_TRACE_ADDR</code>. Do no longer + trace load and store activity for the specified address range. + </p></li> +</ul></div> +<p> +</p> +<p> +Note: if you compiled Valgrind yourself, the header file +<code class="literal"><valgrind/drd.h></code> will have been installed in +the directory <code class="literal">/usr/include</code> by the command +<code class="literal">make install</code>. If you obtained Valgrind by +installing it as a package however, you will probably have to install +another package with a name like <code class="literal">valgrind-devel</code> +before Valgrind's header files are present. +</p> +</div> +<div class="sect2" lang="en"> +<div class="titlepage"><div><div><h3 class="title"> +<a name="drd-manual.gnome"></a>8.2.6.Debugging GNOME Programs</h3></div></div></div> +<p> +GNOME applications use the threading primitives provided by the +<code class="computeroutput">glib</code> and +<code class="computeroutput">gthread</code> libraries. These libraries +are built on top of POSIX threads, and hence are directly supported by +DRD. Please keep in mind that you have to call +<code class="function">g_thread_init()</code> before creating any threads, or +DRD will report several data races on glib functions. See also the +<a href="http://library.gnome.org/devel/glib/stable/glib-Threads.html" target="_top">GLib +Reference Manual</a> for more information about +<code class="function">g_thread_init()</code>. +</p> +<p> +One of the many facilities provided by the <code class="literal">glib</code> +library is a block allocator, called <code class="literal">g_slice</code>. You +have to disable this block allocator when using DRD by adding the +following to the shell environment variables: +<code class="literal">G_SLICE=always-malloc</code>. See also the <a href="http://library.gnome.org/devel/glib/stable/glib-Memory-Slices.html" target="_top">GLib +Reference Manual</a> for more information. +</p> +</div> +<div class="sect2" lang="en"> +<div class="titlepage"><div><div><h3 class="title"> +<a name="drd-manual.qt"></a>8.2.7.Debugging Qt Programs</h3></div></div></div> +<p> +The Qt library is the GUI library used by the KDE project. Currently +there are two versions of the Qt library in use: Qt3 by KDE 3 and Qt4 +by KDE 4. If possible, use Qt4 instead of Qt3. Qt3 is no longer +supported, and there are known problems with multithreading support in +Qt3. As an example, using QString objects in more than one thread will +trigger race reports (this has been confirmed by Trolltech -- see also +Trolltech task <a href="http://trolltech.com/developer/task-tracker/index_html" target="_top">#206152</a>). +</p> +<p> +Qt4 applications are supported by DRD, but only if the +<code class="literal">libqt4-debuginfo</code> package has been installed. Some +of the synchronization and threading primitives in Qt4 bypass the +POSIX threads library, and DRD can only intercept these if symbol +information for the Qt4 library is available. DRD won't tell you if it +has not been able to load the Qt4 debug information, but a huge number +of data races will be reported on data protected via +<code class="literal">QMutex</code> objects. +</p> +</div> +<div class="sect2" lang="en"> +<div class="titlepage"><div><div><h3 class="title"> +<a name="drd-manual.boost.thread"></a>8.2.8.Debugging Boost.Thread Programs</h3></div></div></div> +<p> +The Boost.Thread library is the threading library included with the +cross-platform Boost Libraries. This threading library is an early +implementation of the upcoming C++0x threading library. +</p> +<p> +Applications that use the Boost.Thread library should run fine under DRD. +</p> +<p> +More information about Boost.Thread can be found here: +</p> +<div class="itemizedlist"><ul type="disc"> +<li><p> + Anthony Williams, <a href="http://www.boost.org/doc/libs/1_37_0/doc/html/thread.html" target="_top">Boost.Thread</a> + Library Documentation, Boost website, 2007. + </p></li> +<li><p> + Anthony Williams, <a href="http://www.ddj.com/cpp/211600441" target="_top">What's New in Boost + Threads?</a>, Recent changes to the Boost Thread library, + Dr. Dobbs Magazine, October 2008. + </p></li> +</ul></div> +<p> +</p> +</div> +<div class="sect2" lang="en"> +<div class="titlepage"><div><div><h3 class="title"> +<a name="drd-manual.openmp"></a>8.2.9.Debugging OpenMP Programs</h3></div></div></div> +<p> +OpenMP stands for <span class="emphasis"><em>Open Multi-Processing</em></span>. The +OpenMP standard consists of a set of compiler directives for C, C++ +and Fortran programs that allows a compiler to transform a sequential +program into a parallel program. OpenMP is well suited for HPC +applications and allows to work at a higher level compared to direct +use of the POSIX threads API. While OpenMP ensures that the POSIX API +is used correctly, OpenMP programs can still contain data races. So it +makes sense to verify OpenMP programs with a thread checking tool. +</p> +<p> +DRD supports OpenMP shared-memory programs generated by gcc. The gcc +compiler supports OpenMP since version 4.2.0. Gcc's runtime support +for OpenMP programs is provided by a library called +<code class="literal">libgomp</code>. The synchronization primites implemented +in this library use Linux' futex system call directly, unless the +library has been configured with the +<code class="literal">--disable-linux-futex</code> flag. DRD only supports +libgomp libraries that have been configured with this flag and in +which symbol information is present. For most Linux distributions this +means that you will have to recompile gcc. See also the script +<code class="literal">drd/scripts/download-and-build-gcc</code> in the +Valgrind source tree for an example of how to compile gcc. You will +also have to make sure that the newly compiled +<code class="literal">libgomp.so</code> library is loaded when OpenMP programs +are started. This is possible by adding a line similar to the +following to your shell startup script: +</p> +<pre class="programlisting"> +export LD_LIBRARY_PATH=~/gcc-4.3.2/lib64:~/gcc-4.3.2/lib: +</pre> +<p> +As an example, the test OpenMP test program +<code class="literal">drd/tests/omp_matinv</code> triggers a data race +when the option -r has been specified on the command line. The data +race is triggered by the following code: +</p> +<pre class="programlisting"> +#pragma omp parallel for private(j) +for (j = 0; j < rows; j++) +{ + if (i != j) + { + const elem_t factor = a[j * cols + i]; + for (k = 0; k < cols; k++) + { + a[j * cols + k] -= a[i * cols + k] * factor; + } + } +} +</pre> +<p> +The above code is racy because the variable <code class="literal">k</code> has +not been declared private. DRD will print the following error message +for the above code: +</p> +<pre class="programlisting"> +$ valgrind --check-stack-var=yes --var-info=yes --tool=drd drd/tests/omp_matinv 3 -t 2 -r +... +Conflicting store by thread 1/1 at 0x7fefffbc4 size 4 + at 0x4014A0: gj.omp_fn.0 (omp_matinv.c:203) + by 0x401211: gj (omp_matinv.c:159) + by 0x40166A: invert_matrix (omp_matinv.c:238) + by 0x4019B4: main (omp_matinv.c:316) +Allocation context: unknown. +... +</pre> +<p> +In the above output the function name <code class="function">gj.omp_fn.0</code> +has been generated by gcc from the function name +<code class="function">gj</code>. Unfortunately the variable name +<code class="literal">k</code> 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 +(<code class="literal">omp_matinv.c:203</code>). +</p> +<p> +Note: DRD reports errors on the <code class="literal">libgomp</code> library +included with gcc 4.2.0 up to and including 4.3.2. This might indicate +a race condition in the POSIX version of <code class="literal">libgomp</code>. +</p> +<p> +For more information about OpenMP, see also +<a href="http://openmp.org/" target="_top">openmp.org</a>. +</p> +</div> +<div class="sect2" lang="en"> +<div class="titlepage"><div><div><h3 class="title"> +<a name="drd-manual.cust-mem-alloc"></a>8.2.10.DRD and Custom Memory Allocators</h3></div></div></div> +<p> +DRD tracks all memory allocation events that happen via either the +standard memory allocation and deallocation functions +(<code class="function">malloc</code>, <code class="function">free</code>, +<code class="function">new</code> and <code class="function">delete</code>) or via entry +and exit of stack frames. DRD uses memory allocation and deallocation +information for two purposes: +</p> +<div class="itemizedlist"><ul type="disc"> +<li><p> + To know where the scope ends of POSIX objects that have not been + destroyed explicitly. It is e.g. not required by the POSIX + threads standard to call + <code class="function">pthread_mutex_destroy()</code> before freeing the + memory in which a mutex object resides. + </p></li> +<li><p> + To know where the scope of variables ends. If e.g. heap memory + has been used by one thread, that thread frees that memory, and + another thread allocates and starts using that memory, no data + races must be reported for that memory. + </p></li> +</ul></div> +<p> +</p> +<p> +It is essential for correct operation of DRD that the tool knows about +memory allocation and deallocation events. DRD does not yet support +custom memory allocators, so you will have to make sure that any +program which runs under DRD uses the standard memory allocation +functions. As an example, the GNU libstdc++ library can be configured +to use standard memory allocation functions instead of memory pools by +setting the environment variable +<code class="literal">GLIBCXX_FORCE_NEW</code>. For more information, see also +the <a href="http://gcc.gnu.org/onlinedocs/libstdc++/manual/bk01pt04ch11.html" target="_top">libstdc++ +manual</a>. +</p> +</div> +<div class="sect2" lang="en"> +<div class="titlepage"><div><div><h3 class="title"> +<a name="drd-manual.drd-versus-memcheck"></a>8.2.11.DRD Versus Memcheck</h3></div></div></div> +<p> +It is essential for correct operation of DRD that there are no memory +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 +sense to run DRD before memcheck. +</p> +<p> +So which tool should be run first ? In case both DRD and memcheck +complain about a program, a possible approach is to run both tools +alternatingly and to fix as many errors as possible after each run of +each tool until none of the two tools prints any more error messages. +</p> +</div> +<div class="sect2" lang="en"> +<div class="titlepage"><div><div><h3 class="title"> +<a name="drd-manual.resource-requirements"></a>8.2.12.Resource Requirements</h3></div></div></div> +<p> +The requirements of DRD with regard to heap and stack memory and the +effect on the execution time of client programs are as follows: +</p> +<div class="itemizedlist"><ul type="disc"> +<li><p> + When running a program under DRD with default DRD options, + between 1.1 and 3.6 times more memory will be needed compared to + a native run of the client program. More memory will be needed + if loading debug information has been enabled + (<code class="literal">--var-info=yes</code>). + </p></li> +<li><p> + DRD allocates some of its temporary data structures on the stack + of the client program threads. This amount of data is limited to + 1 - 2 KB. Make sure that thread stacks are sufficiently large. + </p></li> +<li><p> + Most applications will run between 20 and 50 times slower under + DRD than a native single-threaded run. Applications such as + Firefox which perform very much mutex lock / unlock operations + however will run too slow to be usable under DRD. This issue + will be addressed in a future DRD version. + </p></li> +</ul></div> +<p> +</p> +</div> +<div class="sect2" lang="en"> +<div class="titlepage"><div><div><h3 class="title"> +<a name="drd-manual.effective-use"></a>8.2.13.Hints and Tips for Effective Use of DRD</h3></div></div></div> +<p> +The following information may be helpful when using DRD: +</p> +<div class="itemizedlist"><ul type="disc"> +<li><p> + Make sure that debug information is present in the executable + being analysed, such that DRD can print function name and line + number information in stack traces. Most compilers can be told + to include debug information via compiler option + <code class="option">-g</code>. + </p></li> +<li><p> + Compile with flag <code class="option">-O1</code> instead of + <code class="option">-O0</code>. This will reduce the amount of generated + code, may reduce the amount of debug info and will speed up + DRD's processing of the client program. For more information, + see also <a href="manual-core.html#manual-core.started">Getting started</a>. + </p></li> +<li><p> + If DRD reports any errors on libraries that are part of your + Linux distribution like e.g. <code class="literal">libc.so</code> or + <code class="literal">libstdc++.so</code>, installing the debug packages + for these libraries will make the output of DRD a lot more + detailed. + </p></li> +<li> +<p> + When using C++, do not send output from more than one thread to + <code class="literal">std::cout</code>. Doing so would not only + generate multiple data race reports, it could also result in + output from several threads getting mixed up. Either use + <code class="function">printf()</code> or do the following: + </p> +<div class="orderedlist"><ol type="1"> +<li><p>Derive a class from <code class="literal">std::ostreambuf</code> + and let that class send output line by line to + <code class="literal">stdout</code>. This will avoid that individual + lines of text produced by different threads get mixed + up.</p></li> +<li><p>Create one instance of <code class="literal">std::ostream</code> + for each thread. This makes stream formatting settings + thread-local. Pass a per-thread instance of the class + derived from <code class="literal">std::ostreambuf</code> to the + constructor of each instance. </p></li> +<li><p>Let each thread send its output to its own instance of + <code class="literal">std::ostream</code> instead of + <code class="literal">std::cout</code>.</p></li> +</ol></div> +<p> + </p> +</li> +</ul></div> +<p> +</p> +</div> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"><div><div><h2 class="title" style="clear: both"> +<a name="drd-manual.Pthreads"></a>8.3.Using the POSIX Threads API Effectively</h2></div></div></div> +<div class="sect2" lang="en"> +<div class="titlepage"><div><div><h3 class="title"> +<a name="drd-manual.mutex-types"></a>8.3.1.Mutex types</h3></div></div></div> +<p> +The Single UNIX Specification version two defines the following four +mutex types (see also the documentation of <a href="http://www.opengroup.org/onlinepubs/007908799/xsh/pthread_mutexattr_settype.html" target="_top"><code class="function">pthread_mutexattr_settype()</code></a>): +</p> +<div class="itemizedlist"><ul type="disc"> +<li><p> + <span class="emphasis"><em>normal</em></span>, which means that no error checking + is performed, and that the mutex is non-recursive. + </p></li> +<li><p> + <span class="emphasis"><em>error checking</em></span>, which means that the mutex + is non-recursive and that error checking is performed. + </p></li> +<li><p> + <span class="emphasis"><em>recursive</em></span>, which means that a mutex may be + locked recursively. + </p></li> +<li><p> + <span class="emphasis"><em>default</em></span>, which means that error checking + behavior is undefined, and that the behavior for recursive + locking is also undefined. Or: portable code must neither + trigger error conditions through the Pthreads API nor attempt to + lock a mutex of default type recursively. + </p></li> +</ul></div> +<p> +</p> +<p> +In complex applications it is not always clear from beforehand which +mutex will be locked recursively and which mutex will not be locked +recursively. Attempts lock a non-recursive mutex recursively will +result in race conditions that are very hard to find without a thread +checking tool. So either use the error checking mutex type and +consistently check the return value of Pthread API mutex calls, or use +the recursive mutex type. +</p> +</div> +<div class="sect2" lang="en"> +<div class="titlepage"><div><div><h3 class="title"> +<a name="drd-manual.condvar"></a>8.3.2.Condition variables</h3></div></div></div> +<p> +A condition variable allows one thread to wake up one or more other +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 +let threads poll for changes of a state variable that is protected by +a mutex, and to use condition variables only as a thread wakeup +mechanism. See also the source file +<code class="computeroutput">drd/tests/monitor_example.cpp</code> for an +example of how to implement this concept in C++. The monitor concept +used in this example is a well known and very useful concept -- see +also Wikipedia for more information about the <a href="http://en.wikipedia.org/wiki/Monitor_(synchronization)" target="_top">monitor</a> +concept. +</p> +</div> +<div class="sect2" lang="en"> +<div class="titlepage"><div><div><h3 class="title"> +<a name="drd-manual.pctw"></a>8.3.3.pthread_cond_timedwait() and timeouts</h3></div></div></div> +<p> +Historically the function +<code class="function">pthread_cond_timedwait()</code> only allowed the +specification of an absolute timeout, that is a timeout independent of +the time when this function was called. However, almost every call to +this function expresses a relative timeout. This typically happens by +passing the sum of +<code class="computeroutput">clock_gettime(CLOCK_REALTIME)</code> and a +relative timeout as the third argument. This approach is incorrect +since forward or backward clock adjustments by e.g. ntpd will affect +the timeout. A more reliable approach is as follows: +</p> +<div class="itemizedlist"><ul type="disc"> +<li><p> + When initializing a condition variable through + pthread_cond_init(), specify that the timeout of + pthread_cond_timedwait() will use the clock + <code class="literal">CLOCK_MONOTONIC</code> instead of + <code class="literal">CLOCK_REALTIME</code>. You can do this via + <code class="computeroutput">pthread_condattr_setclock(..., + CLOCK_MONOTONIC)</code>. + </p></li> +<li><p> + When calling <code class="function">pthread_cond_timedwait()</code>, pass + the sum of + <code class="computeroutput">clock_gettime(CLOCK_MONOTONIC)</code> + and a relative timeout as the third argument. + </p></li> +</ul></div> +<p> +See also +<code class="computeroutput">drd/tests/monitor_example.cpp</code> for an +example. +</p> +</div> +<div class="sect2" lang="en"> +<div class="titlepage"><div><div><h3 class="title"> +<a name="drd-manual.naming-threads"></a>8.3.4.Assigning names to threads</h3></div></div></div> +<p> +Many applications log information about changes in internal or +external state to a file. When analyzing log files of a multithreaded +application it can be very convenient to know which thread logged +which information. One possible approach is to identify threads in +logging output by including the result of +<code class="function">pthread_self()</code> in every log line. However, this approach +has two disadvantages: there is no direct relationship between these +values and the source code and these values can be different in each +run. A better approach is to assign a brief name to each thread and to +include the assigned thread name in each log line. One possible +approach for managing thread names is as follows: +</p> +<div class="itemizedlist"><ul type="disc"> +<li><p> + Allocate a key for the pointer to the thread name through + <code class="function">pthread_key_create()</code>. + </p></li> +<li><p> + Just after thread creation, set the thread name through + <code class="function">pthread_setspecific()</code>. + </p></li> +<li><p> + In the code that generates the logging information, query the thread + name by calling <code class="function">pthread_getspecific()</code>. + </p></li> +</ul></div> +<p> + +</p> +</div> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"><div><div><h2 class="title" style="clear: both"> +<a name="drd-manual.limitations"></a>8.4.Limitations</h2></div></div></div> +<p>DRD currently has the following limitations:</p> +<div class="itemizedlist"><ul type="disc"> +<li><p> + DRD has only been tested on the Linux operating system, and not + on any of the other operating systems supported by + Valgrind. + </p></li> +<li><p> + Of the two POSIX threads implementations for Linux, only the + NPTL (Native POSIX Thread Library) is supported. The older + LinuxThreads library is not supported. + </p></li> +<li><p> + DRD, just like memcheck, will refuse to start on Linux + distributions where all symbol information has been removed from + ld.so. This is a.o. the case for the PPC editions of openSUSE + and Gentoo. You will have to install the glibc debuginfo package + on these platforms before you can use DRD. See also openSUSE bug + <a href="http://bugzilla.novell.com/show_bug.cgi?id=396197" target="_top"> + 396197</a> and Gentoo bug <a href="http://bugs.gentoo.org/214065" target="_top">214065</a>. + </p></li> +<li><p> + When DRD prints a report about a data race detected on a stack + variable in a parallel section of an OpenMP program, the report + will contain no information about the context of the data race + location (<code class="computeroutput">Allocation context: + unknown</code>). It's not yet clear whether this + behavior is caused by Valgrind or by gcc. + </p></li> +<li><p> + When address tracing is enabled, no information on atomic stores + will be displayed. This functionality is easy to add + however. Please contact the Valgrind authors if you would like + to see this functionality enabled. + </p></li> +<li><p> + If you compile the DRD source code yourself, you need gcc 3.0 or + later. Gcc 2.95 is not supported. + </p></li> +</ul></div> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"><div><div><h2 class="title" style="clear: both"> +<a name="drd-manual.feedback"></a>8.5.Feedback</h2></div></div></div> +<p> +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 <a href="http://www.valgrind.org/" target="_top">http://www.valgrind.org/</a> for more information. +</p> +</div> +</div> +<div> +<br><table class="nav" width="100%" cellspacing="3" cellpadding="2" border="0" summary="Navigation footer"> +<tr> +<td rowspan="2" width="40%" align="left"> +<a accesskey="p" href="hg-manual.html"><<7.Helgrind: a thread error detector</a></td> +<td width="20%" align="center"><a accesskey="u" href="manual.html">Up</a></td> +<td rowspan="2" width="40%" align="right"><a accesskey="n" href="ms-manual.html">9.Massif: a heap profiler>></a> +</td> +</tr> +<tr><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td></tr> +</table> +</div> +</body> +</html> Added: trunk/docs/manual/pc-manual.html =================================================================== --- trunk/docs/manual/pc-manual.html (rev 0) +++ trunk/docs/manual/pc-manual.html 2009-01-03 20:46:17 UTC (rev 371) @@ -0,0 +1,418 @@ +<html> +<head> +<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> +<title>10.Ptrcheck: an (experimental) pointer checking tool</title> +<link rel="stylesheet" href="vg_basic.css" type="text/css"> +<meta name="generator" content="DocBook XSL Stylesheets V1.69.1"> +<link rel="start" href="index.html" title="Valgrind Documentation"> +<link rel="up" href="manual.html" title="Valgrind User Manual"> +<link rel="prev" href="ms-manual.html" title="9.Massif: a heap profiler"> +<link rel="next" href="nl-manual.html" title='11.Nulgrind: the "null" tool'> +</head> +<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"> +<div><table class="nav" width="100%" cellspacing="3" cellpadding="3" border="0" summary="Navigation header"><tr> +<td width="22px" align="center" valign="middle"><a accesskey="p" href="ms-manual.html"><img src="images/prev.png" width="18" height="21" border="0" alt="Prev"></a></td> +<td width="25px" align="center" valign="middle"><a accesskey="u" href="manual.html"><img src="images/up.png" width="21" height="18" border="0" alt="Up"></a></td> +<td width="31px" align="center" valign="middle"><a accesskey="h" href="index.html"><img src="images/home.png" width="27" height="20" border="0" alt="Up"></a></td> +<th align="center" valign="middle">Valgrind User Manual</th> +<td width="22px" align="center" valign="middle"><a accesskey="n" href="nl-manual.html"><img src="images/next.pn... [truncated message content] |
|
From: <sv...@va...> - 2009-01-03 20:33:00
|
Author: bart Date: 2009-01-03 20:32:55 +0000 (Sat, 03 Jan 2009) New Revision: 8906 Log: Removed HAVE_LIBC_FILE_LOCK test. Modified: branches/DRDDEV/configure.in Modified: branches/DRDDEV/configure.in =================================================================== --- branches/DRDDEV/configure.in 2009-01-03 20:32:15 UTC (rev 8905) +++ branches/DRDDEV/configure.in 2009-01-03 20:32:55 UTC (rev 8906) @@ -727,26 +727,6 @@ ]) -# Check whether FILE has a member called _lock and whether it's a pointer. - -AC_MSG_CHECKING([for FILE::_lock]) - -AC_TRY_COMPILE( -[ - #include <stdio.h> -], [ - void *p; - p = stdout->_lock; - return 0; -], [ -AC_MSG_RESULT([yes]) -AC_DEFINE([HAVE_LIBC_FILE_LOCK], 1, - [Define to 1 if FILE has a member called _lock.]) -], [ -AC_MSG_RESULT([no]) -]) - - # Check whether pthread_mutex_t has a member called __m_kind. AC_MSG_CHECKING([for pthread_mutex_t::__m_kind]) |
|
From: <sv...@va...> - 2009-01-03 20:32:21
|
Author: bart
Date: 2009-01-03 20:32:15 +0000 (Sat, 03 Jan 2009)
New Revision: 8905
Log:
Added intercepts for the glibc functions _IO_flockfile and _IO_funlockfile.
Added:
branches/DRDDEV/drd/drd_libc_intercepts.c
Modified:
branches/DRDDEV/drd/Makefile.am
Modified: branches/DRDDEV/drd/Makefile.am
===================================================================
--- branches/DRDDEV/drd/Makefile.am 2009-01-03 20:31:18 UTC (rev 8904)
+++ branches/DRDDEV/drd/Makefile.am 2009-01-03 20:32:15 UTC (rev 8905)
@@ -23,6 +23,7 @@
VGPRELOAD_DRD_SOURCES = \
drd_gomp_intercepts.c \
+ drd_libc_intercepts.c \
drd_pthread_intercepts.c \
drd_qtcore_intercepts.c \
drd_strmem_intercepts.c
Added: branches/DRDDEV/drd/drd_libc_intercepts.c
===================================================================
--- branches/DRDDEV/drd/drd_libc_intercepts.c (rev 0)
+++ branches/DRDDEV/drd/drd_libc_intercepts.c 2009-01-03 20:32:15 UTC (rev 8905)
@@ -0,0 +1,91 @@
+
+/*--------------------------------------------------------------------*/
+/*--- Replacements for functions operating on FILE objects, which ---*/
+/*--- run on the simulated CPU ---*/
+/*--------------------------------------------------------------------*/
+
+/*
+ This file is part of DRD, a heavyweight Valgrind tool for
+ detecting threading errors.
+
+ This program is free software; you can redistribute it and/or
+ modify it under the terms of the GNU General Public License as
+ published by the Free Software Foundation; either version 2 of the
+ License, or (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful, but
+ WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the Free Software
+ Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
+ 02111-1307, USA.
+
+ The GNU General Public License is contained in the file COPYING.
+*/
+
+#include <stdio.h>
+#include "pub_tool_basics.h"
+#include "pub_tool_redir.h"
+#include "valgrind.h"
+#include "drd_clientreq.h"
+
+
+/* --------- Some handy Z-encoded names. --------- */
+
+/* --- Soname of the standard C library. --- */
+
+#if defined(VGO_linux)
+# define m_libc_soname libcZdsoZa // libc.so*
+#elif defined(VGP_ppc32_aix5)
+ /* AIX has both /usr/lib/libc.a and /usr/lib/libc_r.a. */
+# define m_libc_soname libcZaZdaZLshrZdoZR // libc*.a(shr.o)
+#elif defined(VGP_ppc64_aix5)
+# define m_libc_soname libcZaZdaZLshrZu64ZdoZR // libc*.a(shr_64.o)
+#else
+# error "Unknown platform"
+#endif
+
+#define LIBC_FUNC(ret_ty, f, args...) \
+ ret_ty VG_WRAP_FUNCTION_ZZ(m_libc_soname, f)(args); \
+ ret_ty VG_WRAP_FUNCTION_ZZ(m_libc_soname, f)(args)
+
+LIBC_FUNC(int, ZuIOZuflockfile, // _IO_flockfile
+ FILE * stream)
+{
+ int ret;
+ int res;
+ OrigFn fn;
+
+ VALGRIND_GET_ORIG_FN(fn);
+ VALGRIND_DO_CLIENT_REQUEST(res, 0, VG_USERREQ__PRE_MUTEX_LOCK,
+ stream, mutex_type_libio_file, 0, 0, 0);
+ CALL_FN_W_W(ret, fn, stream);
+ VALGRIND_DO_CLIENT_REQUEST(res, 0, VG_USERREQ__POST_MUTEX_LOCK,
+ stream, True, 0, 0, 0);
+ return ret;
+}
+
+LIBC_FUNC(int, ZuIOZufunlockfile, // _IO_funlockfile
+ FILE *stream)
+{
+ int ret;
+ int res;
+ OrigFn fn;
+
+ VALGRIND_GET_ORIG_FN(fn);
+ VALGRIND_DO_CLIENT_REQUEST(res, -1,
+ VG_USERREQ__PRE_MUTEX_UNLOCK,
+ stream, mutex_type_libio_file, 0, 0, 0);
+ CALL_FN_W_W(ret, fn, stream);
+ VALGRIND_DO_CLIENT_REQUEST(res, -1,
+ VG_USERREQ__POST_MUTEX_UNLOCK,
+ stream, 0, 0, 0, 0);
+ return ret;
+}
+
+/*--------------------------------------------------------------------*/
+/*--- end ---*/
+/*--------------------------------------------------------------------*/
|
|
From: <sv...@va...> - 2009-01-03 20:31:25
|
Author: bart
Date: 2009-01-03 20:31:18 +0000 (Sat, 03 Jan 2009)
New Revision: 8904
Log:
Removed stdout/stderr race suppression hack.
Modified:
branches/DRDDEV/drd/drd_pthread_intercepts.c
Modified: branches/DRDDEV/drd/drd_pthread_intercepts.c
===================================================================
--- branches/DRDDEV/drd/drd_pthread_intercepts.c 2009-01-03 17:46:13 UTC (rev 8903)
+++ branches/DRDDEV/drd/drd_pthread_intercepts.c 2009-01-03 20:31:18 UTC (rev 8904)
@@ -98,15 +98,6 @@
{
check_threading_library();
vg_set_main_thread_state();
- /* glibc up to and including version 2.8 triggers conflicting accesses */
- /* on stdout and stderr when sending output to one of these streams from */
- /* more than one thread. Suppress data race reports on these objects. */
- DRD_IGNORE_VAR(*stdout);
- DRD_IGNORE_VAR(*stderr);
-#if defined(HAVE_LIBC_FILE_LOCK)
- DRD_IGNORE_VAR(*(pthread_mutex_t*)(stdout->_lock));
- DRD_IGNORE_VAR(*(pthread_mutex_t*)(stderr->_lock));
-#endif
}
static MutexT pthread_to_drd_mutex_type(const int kind)
|
|
From: Julian S. <js...@ac...> - 2009-01-03 20:00:47
|
We are pleased to announce a new release of Valgrind, version 3.4.0, available from http://www.valgrind.org. Valgrind is an open-source suite of simulation based debugging and profiling tools. With the tools that come with Valgrind, you can automatically detect many memory management and threading bugs, which avoids hours of frustrating bug-hunting, and makes your code more stable. You can also perform detailed time and space profiling to help speed up and slim down your programs. 3.4.0 is a feature release with many significant improvements and the usual collection of bug fixes. This release supports X86/Linux, AMD64/Linux, PPC32/Linux and PPC64/Linux. See the release notes below for details. Our thanks to all those who contribute to Valgrind's development. This release represents a great deal of time, energy and effort on the part of many people. Happy (and productive) debugging and profiling, -- The Valgrind Developers Release 3.4.0 (2 January 2009) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 3.4.0 is a feature release with many significant improvements and the usual collection of bug fixes. This release supports X86/Linux, AMD64/Linux, PPC32/Linux and PPC64/Linux. Support for recent distros (using gcc 4.4, glibc 2.8 and 2.9) has been added. 3.4.0 brings some significant tool improvements. Memcheck can now report the origin of uninitialised values, the thread checkers Helgrind and Drd are much improved, and we have a new experimental tool, exp-Ptrcheck, which is able to detect overruns of stack and global arrays. In detail: * Memcheck is now able to track the origin of uninitialised values. When it reports an uninitialised value error, it will try to show the origin of the value, as either a heap or stack allocation. Origin tracking is expensive and so is not enabled by default. To use it, specify --track-origins=yes. Memcheck's speed will be essentially halved, and memory usage will be significantly increased. Nevertheless it can drastically reduce the effort required to identify the root cause of uninitialised value errors, and so is often a programmer productivity win, despite running more slowly. * A version (1.4.0) of the Valkyrie GUI, that works with Memcheck in 3.4.0, will be released shortly. * Helgrind's race detection algorithm has been completely redesigned and reimplemented, to address usability and scalability concerns: - The new algorithm has a lower false-error rate: it is much less likely to report races that do not really exist. - Helgrind will display full call stacks for both accesses involved in a race. This makes it easier to identify the root causes of races. - Limitations on the size of program that can run have been removed. - Performance has been modestly improved, although that is very workload-dependent. - Direct support for Qt4 threading has been added. - pthread_barriers are now directly supported. - Helgrind works well on all supported Linux targets. * The Drd thread debugging tool has seen major improvements: - Greatly improved performance and significantly reduced memory usage. - Support for several major threading libraries (Boost.Thread, Qt4, glib, OpenMP) has been added. - Support for atomic instructions, POSIX semaphores, barriers and reader-writer locks has been added. - Works now on PowerPC CPUs too. - Added support for printing thread stack usage at thread exit time. - Added support for debugging lock contention. - Added a manual for Drd. * A new experimental tool, exp-Ptrcheck, has been added. Ptrcheck checks for misuses of pointers. In that sense it is a bit like Memcheck. However, Ptrcheck can do things Memcheck can't: it can detect overruns of stack and global arrays, it can detect arbitrarily far out-of-bounds accesses to heap blocks, and it can detect accesses heap blocks that have been freed a very long time ago (millions of blocks in the past). Ptrcheck currently works only on x86-linux and amd64-linux. To use it, use --tool=exp-ptrcheck. A simple manual is provided, as part of the main Valgrind documentation. As this is an experimental tool, we would be particularly interested in hearing about your experiences with it. * exp-Omega, an experimental instantaneous leak-detecting tool, is no longer built by default, although the code remains in the repository and the tarball. This is due to three factors: a perceived lack of users, a lack of maintenance, and concerns that it may not be possible to achieve reliable operation using the existing design. * As usual, support for the latest Linux distros and toolchain components has been added. It should work well on Fedora Core 10, OpenSUSE 11.1 and Ubuntu 8.10. gcc-4.4 (in its current pre-release state) is supported, as is glibc-2.9. The C++ demangler has been updated so as to work well with C++ compiled by even the most recent g++'s. * You can now use frame-level wildcards in suppressions. This was a frequently-requested enhancement. A line "..." in a suppression now matches zero or more frames. This makes it easier to write suppressions which are precise yet insensitive to changes in inlining behaviour. * 3.4.0 adds support on x86/amd64 for the SSSE3 instruction set. * Very basic support for IBM Power6 has been added (64-bit processes only). * Valgrind is now cross-compilable. For example, it is possible to cross compile Valgrind on an x86/amd64-linux host, so that it runs on a ppc32/64-linux target. * You can set the main thread's stack size at startup using the new --main-stacksize= flag (subject of course to ulimit settings). This is useful for running apps that need a lot of stack space. * The limitation that you can't use --trace-children=yes together with --db-attach=yes has been removed. * The following bugs have been fixed. Note that "n-i-bz" stands for "not in bugzilla" -- that is, a bug that was reported to us but never got a bugzilla entry. We encourage you to file bugs in bugzilla (http://bugs.kde.org/enter_valgrind_bug.cgi) rather than mailing the developers (or mailing lists) directly. n-i-bz Make return types for some client requests 64-bit clean n-i-bz glibc 2.9 support n-i-bz ignore unsafe .valgrindrc's (CVE-2008-4865) n-i-bz MPI_Init(0,0) is valid but libmpiwrap.c segfaults n-i-bz Building in an env without gdb gives bogus gdb attach 92456 Tracing the origin of uninitialised memory 106497 Valgrind does not demangle some C++ template symbols 162222 ==106497 151612 Suppression with "..." (frame-level wildcards in .supp files) 156404 Unable to start oocalc under memcheck on openSUSE 10.3 (64-bit) 159285 unhandled syscall:25 (stime, on x86-linux) 159452 unhandled ioctl 0x8B01 on "valgrind iwconfig" 160954 ppc build of valgrind crashes with illegal instruction (isel) 160956 mallinfo implementation, w/ patch 162092 Valgrind fails to start gnome-system-monitor 162819 malloc_free_fill test doesn't pass on glibc2.8 x86 163794 assertion failure with "--track-origins=yes" 163933 sigcontext.err and .trapno must be set together 163955 remove constraint !(--db-attach=yes && --trace-children=yes) 164476 Missing kernel module loading system calls 164669 SVN regression: mmap() drops posix file locks 166581 Callgrind output corruption when program forks 167288 Patch file for missing system calls on Cell BE 168943 unsupported scas instruction pentium 171645 Unrecognised instruction (MOVSD, non-binutils encoding) 172417 x86->IR: 0x82 ... 172563 amd64->IR: 0xD9 0xF5 - fprem1 173099 .lds linker script generation error 173177 [x86_64] syscalls: 125/126/179 (capget/capset/quotactl) 173751 amd64->IR: 0x48 0xF 0x6F 0x45 (even more redundant prefixes) 174532 == 173751 174908 --log-file value not expanded correctly for core file 175044 Add lookup_dcookie for amd64 175150 x86->IR: 0xF2 0xF 0x11 0xC1 (movss non-binutils encoding) Developer-visible changes: * Valgrind's debug-info reading machinery has been majorly overhauled. It can now correctly establish the addresses for ELF data symbols, which is something that has never worked properly before now. Also, Valgrind can now read DWARF3 type and location information for stack and global variables. This makes it possible to use the framework to build tools that rely on knowing the type and locations of stack and global variables, for example exp-Ptrcheck. Reading of such information is disabled by default, because most tools don't need it, and because it is expensive in space and time. However, you can force Valgrind to read it, using the --read-var-info=yes flag. Memcheck, Helgrind and DRD are able to make use of such information, if present, to provide source-level 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 r8899). |
|
From: <sv...@va...> - 2009-01-03 18:29:58
|
Author: sewardj Date: 2009-01-03 18:29:51 +0000 (Sat, 03 Jan 2009) New Revision: 370 Log: rm redundant verbiage. Modified: trunk/downloads/current.html Modified: trunk/downloads/current.html =================================================================== --- trunk/downloads/current.html 2009-01-03 18:22:56 UTC (rev 369) +++ trunk/downloads/current.html 2009-01-03 18:29:51 UTC (rev 370) @@ -30,8 +30,8 @@ </p> <p> - 3.4.0 is a feature release with many significant improvements and the - usual collection of bug fixes. This release supports X86/Linux, + 3.4.0 is a feature release with many improvements and the usual + collection of bug fixes. This release supports X86/Linux, AMD64/Linux, PPC32/Linux and PPC64/Linux. Support for recent distros (using gcc 4.4, glibc 2.8 and 2.9) has been added.</p> <p> @@ -40,7 +40,7 @@ Helgrind and DRD are much improved, and we have a new experimental tool, exp-Ptrcheck, which is able to detect overruns of stack and global arrays. There are many other smaller refinements and - improvements, and of course the usual collection of bug fixes.</p> + improvements.</p> |
|
From: <sv...@va...> - 2009-01-03 18:23:02
|
Author: sewardj Date: 2009-01-03 18:22:56 +0000 (Sat, 03 Jan 2009) New Revision: 369 Log: Updates for 3.4.0. Modified: trunk/docs/manual/dist.news.html trunk/downloads/current.html trunk/index.html trunk/php/.htconfx Modified: trunk/docs/manual/dist.news.html =================================================================== --- trunk/docs/manual/dist.news.html 2008-12-24 23:27:25 UTC (rev 368) +++ trunk/docs/manual/dist.news.html 2009-01-03 18:22:56 UTC (rev 369) @@ -22,6 +22,185 @@ <a name="dist.news"></a>4.NEWS</h2></div></div></div> <div class="literallayout"><p><br> <br> +Release3.4.0(2January2009)<br> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br> +3.4.0isafeaturereleasewithmanysignificantimprovementsandthe<br> +usualcollectionofbugfixes.ThisreleasesupportsX86/Linux,<br> +AMD64/Linux,PPC32/LinuxandPPC64/Linux.Supportforrecentdistros<br> +(usinggcc4.4,glibc2.8and2.9)hasbeenadded.<br> +<br> +3.4.0bringssomesignificanttoolimprovements.Memcheckcannow<br> +reporttheoriginofuninitialisedvalues,thethreadcheckers<br> +HelgrindandDRDaremuchimproved,andwehaveanewexperimental<br> +tool,exp-Ptrcheck,whichisabletodetectoverrunsofstackand<br> +globalarrays.Indetail:<br> +<br> +*Memcheckisnowabletotracktheoriginofuninitialisedvalues.<br> +Whenitreportsanuninitialisedvalueerror,itwilltrytoshow<br> +theoriginofthevalue,aseitheraheaporstackallocation.<br> +Origintrackingisexpensiveandsoisnotenabledbydefault.To<br> +useit,specify--track-origins=yes.Memcheck'sspeedwillbe<br> +essentiallyhalved,andmemoryusagewillbesignificantly<br> +increased.Neverthelessitcandrasticallyreducetheeffort<br> +requiredtoidentifytherootcauseofuninitialisedvalueerrors,<br> +andsoisoftenaprogrammerproductivitywin,despiterunningmore<br> +slowly.<br> +<br> +*Aversion(1.4.0)oftheValkyrieGUI,thatworkswithMemcheckin<br> +3.4.0,willbereleasedshortly.<br> +<br> +*Helgrind'sracedetectionalgorithmhasbeencompletelyredesigned<br> +andreimplemented,toaddressusabilityandscalabilityconcerns:<br> +<br> +-Thenewalgorithmhasalowerfalse-errorrate:itismuchless<br> +likelytoreportracesthatdonotreallyexist.<br> +<br> +-Helgrindwilldisplayfullcallstacksforbothaccessesinvolved<br> +inarace.Thismakesiteasiertoidentifytherootcausesof<br> +races.<br> +<br> +-Limitationsonthesizeofprogramthatcanrunhavebeenremoved.<br> +<br> +-Performancehasbeenmodestlyimproved,althoughthatisvery<br> +workload-dependent.<br> +<br> +-DirectsupportforQt4threadinghasbeenadded.<br> +<br> +-pthread_barriersarenowdirectlysupported.<br> +<br> +-HelgrindworkswellonallsupportedLinuxtargets.<br> +<br> +*TheDRDthreaddebuggingtoolhasseenmajorimprovements:<br> +<br> +-Greatlyimprovedperformanceandsignificantlyreducedmemory<br> +usage.<br> +<br> +-Supportforseveralmajorthreadinglibraries(Boost.Thread,Qt4,<br> +glib,OpenMP)hasbeenadded.<br> +<br> +-Supportforatomicinstructions,POSIXsemaphores,barriersand<br> +reader-writerlockshasbeenadded.<br> +<br> +-WorksnowonPowerPCCPUstoo.<br> +<br> +-Addedsupportforprintingthreadstackusageatthreadexittime.<br> +<br> +-Addedsupportfordebugginglockcontention.<br> +<br> +-AddedamanualforDrd.<br> +<br> +*Anewexperimentaltool,exp-Ptrcheck,hasbeenadded.Ptrcheck<br> +checksformisusesofpointers.Inthatsenseitisabitlike<br> +Memcheck.However,PtrcheckcandothingsMemcheckcan't:itcan<br> +detectoverrunsofstackandglobalarrays,itcandetect<br> +arbitrarilyfarout-of-boundsaccessestoheapblocks,anditcan<br> +detectaccessesheapblocksthathavebeenfreedaverylongtime<br> +ago(millionsofblocksinthepast).<br> +<br> +Ptrcheckcurrentlyworksonlyonx86-linuxandamd64-linux.Touse<br> +it,use--tool=exp-ptrcheck.Asimplemanualisprovided,aspart<br> +ofthemainValgrinddocumentation.Asthisisanexperimental<br> +tool,wewouldbeparticularlyinterestedinhearingaboutyour<br> +experienceswithit.<br> +<br> +*exp-Omega,anexperimentalinstantaneousleak-detectingtool,isno<br> +longerbuiltbydefault,althoughthecoderemainsintherepository<br> +andthetarball.Thisisduetothreefactors:aperceivedlackof<br> +users,alackofmaintenance,andconcernsthatitmaynotbe<br> +possibletoachievereliableoperationusingtheexistingdesign.<br> +<br> +*Asusual,supportforthelatestLinuxdistrosandtoolchain<br> +componentshasbeenadded.ItshouldworkwellonFedoraCore10,<br> +OpenSUSE11.1andUbuntu8.10.gcc-4.4(initscurrentpre-release<br> +state)issupported,asisglibc-2.9.TheC++demanglerhasbeen<br> +updatedsoastoworkwellwithC++compiledbyeventhemostrecent<br> +g++'s.<br> +<br> +*Youcannowuseframe-levelwildcardsinsuppressions.Thiswasa<br> +frequently-requestedenhancement.Aline"..."inasuppressionnow<br> +matcheszeroormoreframes.Thismakesiteasiertowrite<br> +suppressionswhicharepreciseyetinsensitivetochangesin<br> +inliningbehaviour.<br> +<br> +*3.4.0addssupportonx86/amd64fortheSSSE3instructionset.<br> +<br> +*VerybasicsupportforIBMPower6hasbeenadded(64-bitprocessesonly).<br> +<br> +*Valgrindisnowcross-compilable.Forexample,itispossibleto<br> +crosscompileValgrindonanx86/amd64-linuxhost,sothatitruns<br> +onappc32/64-linuxtarget.<br> +<br> +*Youcansetthemainthread'sstacksizeatstartupusingthe<br> +new--main-stacksize=flag(subjectofcoursetoulimitsettings).<br> +Thisisusefulforrunningappsthatneedalotofstackspace.<br> +<br> +*Thelimitationthatyoucan'tuse--trace-children=yestogether<br> +with--db-attach=yeshasbeenremoved.<br> +<br> +*Thefollowingbugshavebeenfixed.Notethat"n-i-bz"standsfor<br> +"notinbugzilla"--thatis,abugthatwasreportedtousbut<br> +nevergotabugzillaentry.Weencourageyoutofilebugsin<br> +bugzilla(http://bugs.kde.org/enter_valgrind_bug.cgi)ratherthan<br> +mailingthedevelopers(ormailinglists)directly.<br> +<br> +n-i-bzMakereturntypesforsomeclientrequests64-bitclean<br> +n-i-bzglibc2.9support<br> +n-i-bzignoreunsafe.valgrindrc's(CVE-2008-4865)<br> +n-i-bzMPI_Init(0,0)isvalidbutlibmpiwrap.csegfaults<br> +n-i-bzBuildinginanenvwithoutgdbgivesbogusgdbattach<br> +92456Tracingtheoriginofuninitialisedmemory<br> +106497ValgrinddoesnotdemanglesomeC++templatesymbols<br> +162222==106497<br> +151612Suppressionwith"..."(frame-levelwildcardsin.suppfiles)<br> +156404UnabletostartoocalcundermemcheckonopenSUSE10.3(64-bit)<br> +159285unhandledsyscall:25(stime,onx86-linux)<br> +159452unhandledioctl0x8B01on"valgrindiwconfig"<br> +160954ppcbuildofvalgrindcrasheswithillegalinstruction(isel)<br> +160956mallinfoimplementation,w/patch<br> +162092Valgrindfailstostartgnome-system-monitor<br> +162819malloc_free_filltestdoesn'tpassonglibc2.8x86<br> +163794assertionfailurewith"--track-origins=yes"<br> +163933sigcontext.errand.trapnomustbesettogether<br> +163955removeconstraint!(--db-attach=yes&&--trace-children=yes)<br> +164476Missingkernelmoduleloadingsystemcalls<br> +164669SVNregression:mmap()dropsposixfilelocks<br> +166581Callgrindoutputcorruptionwhenprogramforks<br> +167288PatchfileformissingsystemcallsonCellBE<br> +168943unsupportedscasinstructionpentium<br> +171645Unrecognisedinstruction(MOVSD,non-binutilsencoding)<br> +172417x86->IR:0x82...<br> +172563amd64->IR:0xD90xF5-fprem1<br> +173099.ldslinkerscriptgenerationerror<br> +173177[x86_64]syscalls:125/126/179(capget/capset/quotactl)<br> +173751amd64->IR:0x480xF0x6F0x45(evenmoreredundantprefixes)<br> +174532==173751<br> +174908--log-filevaluenotexpandedcorrectlyforcorefile<br> +175044Addlookup_dcookieforamd64<br> +175150x86->IR:0xF20xF0x110xC1(movssnon-binutilsencoding)<br> +<br> +Developer-visiblechanges:<br> +<br> +*Valgrind'sdebug-inforeadingmachineryhasbeenmajorlyoverhauled.<br> +ItcannowcorrectlyestablishtheaddressesforELFdatasymbols,<br> +whichissomethingthathasneverworkedproperlybeforenow.<br> +<br> +Also,ValgrindcannowreadDWARF3typeandlocationinformationfor<br> +stackandglobalvariables.Thismakesitpossibletousethe<br> +frameworktobuildtoolsthatrelyonknowingthetypeandlocations<br> +ofstackandglobalvariables,forexampleexp-Ptrcheck.<br> +<br> +Readingofsuchinformationisdisabledbydefault,becausemost<br> +toolsdon'tneedit,andbecauseitisexpensiveinspaceandtime.<br> +However,youcanforceValgrindtoreadit,usingthe<br> +--read-var-info=yesflag.Memcheck,HelgrindandDRDareableto<br> +makeuseofsuchinformation,ifpresent,toprovidesource-level<br> +descriptionsofdataaddressesintheerrormessagestheycreate.<br> +<br> +(3.4.0.RC1:24Dec2008,vexr1878,valgrindr8882).<br> +(3.4.0:3Jan2009,vexr1878,valgrindr8899).<br> +<br> +<br> +<br> Release3.3.1(4June2008)<br> ~~~~~~~~~~~~~~~~~~~~~~~~~~~<br> 3.3.1fixesabunchofbugsin3.3.0,addssupportforglibc-2.8based<br> Modified: trunk/downloads/current.html =================================================================== --- trunk/downloads/current.html 2008-12-24 23:27:25 UTC (rev 368) +++ trunk/downloads/current.html 2009-01-03 18:22:56 UTC (rev 369) @@ -18,70 +18,33 @@ <div id="release"> -<a name="current"><h3>Release 3.4.0 (Release Candidate 1)</h3></a> +<a name="current"><h3>Release 3.4.0</h3></a> -<p><a href="/downloads/valgrind-3.4.0.RC1.tar.bz2">valgrind 3.4.0.RC1 - (tar.bz2)</a> -[5176Kb] - 24 Dec 2008.<br /> +<p><a href="/downloads/valgrind-3.4.0.tar.bz2">valgrind 3.4.0 (tar.bz2)</a> +[5175Kb] - 2 Jan 2009.<br /> For {x86,amd64,ppc32,ppc64}-linux.<br /> -<span class="md5sum">md5: 9378295e0c8049a86a7b4fa7ca93eed1</span></p> +<span class="md5sum">md5: 1b0fe1219e1a583ff8c2db54ed2265e6</span></p> -<p> - This is a release candidate for 3.4.0. It is not the final release. - It is provided for testing by early adopters. If you are looking for - the current stable release, don't use this -- instead use 3.3.1 - below.</p> -<p> - Please give it a try on whatever platforms are important for you. - Unless any showstopper bugs appear, the final 3.4.0 release will be - on 2 January 2009.</p> - -<p>The NEWS file in the tarball contains a detailed list of changes. - Here's a summary:</p> -<ul> - <li>Memcheck: can now show you the origins of uninitialised values</li> - <li>Helgrind: increased accuracy, scalability, and better error messages</li> - <li>Drd: improved performance, reduced memory use, more functionality</li> - <li>exp-Ptrcheck: a new tool to detect overruns of stack/global arrays</li> - <li>support for latest Linux distros, including gcc-4.4 and glibc-2.9</li> - <li>frame-level wildcards in suppressions (a frequently requested feature)</li> - <li>Support for the SSSE3 instruction set on x86/amd64</li> - <li>Many bug fixes</li> -</ul> - - - - - -<div id="release"> - -<a name="current"><h3>Release 3.3.1 (Current Stable version)</h3></a> - -<p><a href="/downloads/valgrind-3.3.1.tar.bz2">valgrind 3.3.1 (tar.bz2)</a> -[4544Kb] - 4 June 2008.<br /> -For {x86,amd64,ppc32,ppc64}-linux.<br /> -<span class="md5sum">md5: 0539e2fa4aadb2cd4ca4bba65b1fe8b5</span></p> - <p>You may want to look at the -<a href="/docs/manual/dist.news.html">3.3.1 release notes</a>. +<a href="/docs/manual/dist.news.html">3.4.0 release notes</a>. </p> -<p>3.3.1 fixes a bunch of bugs in 3.3.0, adds support for glibc-2.8 based -systems (openSUSE 11, Fedora Core 9), improves the existing glibc-2.7 -support, and adds support for the SSSE3 (Core 2) instruction set.</p> +<p> + 3.4.0 is a feature release with many significant improvements and the + usual collection of bug fixes. This release supports X86/Linux, + AMD64/Linux, PPC32/Linux and PPC64/Linux. Support for recent distros + (using gcc 4.4, glibc 2.8 and 2.9) has been added.</p> +<p> + 3.4.0 brings some significant tool improvements. Memcheck can now + report the origin of uninitialised values, the thread checkers + Helgrind and DRD are much improved, and we have a new experimental + tool, exp-Ptrcheck, which is able to detect overruns of stack and + global arrays. There are many other smaller refinements and + improvements, and of course the usual collection of bug fixes.</p> -<p>3.3.1 builds and runs its regression tests on at least the following -platforms, and probably more:</p> -<ul> - <li>x86: RedHat 7.3, 8, 9, SuSE 10.1, 10.2, 11.0rc1, Fedora 9</li> - <li>amd64: SuSE 10.2, 11.0rc1, Ubuntu 8.04</li> - <li>ppc32: Fedora 8, 9</li> - <li>ppc64: Fedora 8, 9</li> -</ul> - <div class="hr_brown"><hr/></div> <h3>Valkyrie 1.3.0</h3> @@ -91,11 +54,15 @@ <span class="md5sum">md5: ec7069a23ec90670be74d3fc3a46f574</span></p> <p><a href="http://www.open-works.co.uk/projects/valkyrie.html">Valkyrie</a> -is a GUI for valgrind 3.3.0 or higher. It also has an XML merging tool for +is a GUI for valgrind 3.3.0 and 3.3.1. It also has an XML merging tool for Memcheck outputs (vk_logmerge). This tarball is known to build and work with valgrind-3.3.0.</p> +<p>This version of Valkyrie does not support the new Valgrind 3.4.0 + release. However, we plan to release a new Valkyrie version (1.4.0) + on or before 9 Jan 2009, which does support Valgrind 3.4.0.</p> + <div class="hr_brown"><hr/></div> <h3>RPMs / Binaries</h3> Modified: trunk/index.html =================================================================== --- trunk/index.html 2008-12-24 23:27:25 UTC (rev 368) +++ trunk/index.html 2009-01-03 18:22:56 UTC (rev 369) @@ -19,12 +19,13 @@ use Valgrind to build new tools. </p> -<p>The Valgrind distribution currently includes five production-quality -tools: a memory error detector, a thread error detector, a cache and -branch-prediction profiler, a call-graph generating cache profiler, and a -heap profiler. It also includes two experimental tools: a data race -detector, and an instant memory leak detector. It runs on the following -platforms: X86/Linux, AMD64/Linux, PPC32/Linux, PPC64/Linux.</p> +<p>The Valgrind distribution currently includes six production-quality +tools: a memory error detector, two thread error detectors, a cache +and branch-prediction profiler, a call-graph generating cache +profiler, and a heap profiler. It also includes one experimental +tool, which detects out of bounds reads and writes of stack, global +and heap arrays. It runs on the following platforms: X86/Linux, +AMD64/Linux, PPC32/Linux, PPC64/Linux.</p> <p>Valgrind is <a href="http://www.opensource.org/">Open Source</a> / <a href="http://www.gnu.org/philosophy/free-sw.html">Free Software</a>, Modified: trunk/php/.htconfx =================================================================== --- trunk/php/.htconfx 2008-12-24 23:27:25 UTC (rev 368) +++ trunk/php/.htconfx 2009-01-03 18:22:56 UTC (rev 369) @@ -24,11 +24,11 @@ 'inc_dir' => $base_dir . '/php/', 'img_dir' => $base_dir . '/images/', - 'dt_copyright' => '2000-2008', + 'dt_copyright' => '2000-2009', /* current release info */ - 'release-date' => '4 June 2008', - 'release-version' => 'valgrind-3.3.1', + 'release-date' => '2 January 2009', + 'release-version' => 'valgrind-3.4.0', /* mailing lists, bug reports, etc. */ 'vgannounce' => array( |
|
From: <sv...@va...> - 2009-01-03 17:46:17
|
Author: sewardj Date: 2009-01-03 17:46:13 +0000 (Sat, 03 Jan 2009) New Revision: 8903 Log: Swizzle the external, to vex/branches/VEX_3_4_BRANCH. Modified: branches/VALGRIND_3_4_BRANCH/ Property changes on: branches/VALGRIND_3_4_BRANCH ___________________________________________________________________ Name: svn:externals - VEX svn://svn.valgrind.org/vex/trunk + VEX svn://svn.valgrind.org/vex/branches/VEX_3_4_BRANCH |
|
From: <sv...@va...> - 2009-01-03 17:38:03
|
Author: sewardj Date: 2009-01-03 17:37:50 +0000 (Sat, 03 Jan 2009) New Revision: 8902 Log: Swizzle the external, to vex/tags/VEX_3_4_0. Modified: tags/VALGRIND_3_4_0/ Property changes on: tags/VALGRIND_3_4_0 ___________________________________________________________________ Name: svn:externals - VEX svn://svn.valgrind.org/vex/trunk + VEX svn://svn.valgrind.org/vex/tags/VEX_3_4_0 |
|
From: <sv...@va...> - 2009-01-03 17:35:26
|
Author: sewardj Date: 2009-01-03 17:35:15 +0000 (Sat, 03 Jan 2009) New Revision: 1880 Log: Make a copy of trunk r1878, to form the start of the 3_4_BRANCH. Added: branches/VEX_3_4_BRANCH/ Copied: branches/VEX_3_4_BRANCH (from rev 1878, trunk) Property changes on: branches/VEX_3_4_BRANCH ___________________________________________________________________ Name: svn:ignore + libvex*.a TAG_* Name: svn:mergeinfo + |
|
From: <sv...@va...> - 2009-01-03 17:34:37
|
Author: sewardj Date: 2009-01-03 17:34:32 +0000 (Sat, 03 Jan 2009) New Revision: 1879 Log: Make a copy of trunk r1878, as the released 3.4.0. Added: tags/VEX_3_4_0/ Copied: tags/VEX_3_4_0 (from rev 1878, trunk) Property changes on: tags/VEX_3_4_0 ___________________________________________________________________ Name: svn:ignore + libvex*.a TAG_* Name: svn:mergeinfo + |
|
From: <sv...@va...> - 2009-01-03 17:31:49
|
Author: sewardj Date: 2009-01-03 17:31:46 +0000 (Sat, 03 Jan 2009) New Revision: 8901 Log: Make a copy of trunk r8899, to form the start of 3_4_BRANCH. Added: branches/VALGRIND_3_4_BRANCH/ Copied: branches/VALGRIND_3_4_BRANCH (from rev 8899, trunk) Property changes on: branches/VALGRIND_3_4_BRANCH ___________________________________________________________________ Name: svn:ignore + acinclude.m4 aclocal.m4 autom4te-*.cache autom4te.cache bin cachegrind cachegrind.out.* compile config.guess config.h* config.log config.status config.sub configure default.supp glibc-2.X.supp depcomp include .in_place install-sh lib Makefile Makefile.in missing mkinstalldirs share stamp-h* svn-commit.tmp svn-commit.2.tmp valgrind valgrind.pc valgrind.spec valt_load_address*.lds vg_annotate vg_cachegen Name: svn:externals + VEX svn://svn.valgrind.org/vex/trunk Name: svn:mergeinfo + |
|
From: <sv...@va...> - 2009-01-03 17:31:07
|
Author: sewardj Date: 2009-01-03 17:31:00 +0000 (Sat, 03 Jan 2009) New Revision: 8900 Log: Make a copy of trunk r8899, as the released 3.4.0. Added: tags/VALGRIND_3_4_0/ Copied: tags/VALGRIND_3_4_0 (from rev 8899, trunk) Property changes on: tags/VALGRIND_3_4_0 ___________________________________________________________________ Name: svn:ignore + acinclude.m4 aclocal.m4 autom4te-*.cache autom4te.cache bin cachegrind cachegrind.out.* compile config.guess config.h* config.log config.status config.sub configure default.supp glibc-2.X.supp depcomp include .in_place install-sh lib Makefile Makefile.in missing mkinstalldirs share stamp-h* svn-commit.tmp svn-commit.2.tmp valgrind valgrind.pc valgrind.spec valt_load_address*.lds vg_annotate vg_cachegen Name: svn:externals + VEX svn://svn.valgrind.org/vex/trunk Name: svn:mergeinfo + |
|
From: Tom H. <th...@cy...> - 2009-01-03 06:39:10
|
Nightly build on lloyd ( x86_64, Fedora 7 ) started at 2009-01-03 03:05:04 GMT 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 == 472 tests, 8 stderr failures, 1 stdout failure, 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) memcheck/tests/x86/scalar (stderr) none/tests/blockfault (stderr) none/tests/res_search (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 == 472 tests, 8 stderr failures, 0 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) memcheck/tests/x86/scalar (stderr) none/tests/blockfault (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Sat Jan 3 03:22:02 2009 --- new.short Sat Jan 3 03:39:45 2009 *************** *** 8,10 **** ! == 472 tests, 8 stderr failures, 0 stdout failures, 0 post failures == exp-ptrcheck/tests/base (stderr) --- 8,10 ---- ! == 472 tests, 8 stderr failures, 1 stdout failure, 0 post failures == exp-ptrcheck/tests/base (stderr) *************** *** 17,18 **** --- 17,19 ---- none/tests/blockfault (stderr) + none/tests/res_search (stdout) |
|
From: Tom H. <th...@cy...> - 2009-01-03 06:39:06
|
Nightly build on trojan ( x86_64, Fedora Core 6 ) started at 2009-01-03 03:25:04 GMT Results differ from 24 hours ago Checking out valgrind source tree ... failed Last 20 lines of verbose log follow echo Checking out valgrind source tree ... svn co svn://svn.valgrind.org/valgrind/trunk -r {2009-01-03T03:25:04} valgrind svn: Can't connect to host 'svn.valgrind.org': Connection timed out ================================================= == 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 == 476 tests, 8 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/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) none/tests/res_search (stdout) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Sat Jan 3 03:37:15 2009 --- new.short Sat Jan 3 03:40:24 2009 *************** *** 1,23 **** ! 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, 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/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) ! none/tests/res_search (stdout) --- 1,7 ---- ! Checking out valgrind source tree ... failed ! Last 20 lines of verbose log follow echo + Checking out valgrind source tree ... svn co svn://svn.valgrind.org/valgrind/trunk -r {2009-01-03T03:25:04} valgrind + svn: Can't connect to host 'svn.valgrind.org': Connection timed out |
|
From: Tom H. <th...@cy...> - 2009-01-03 06:39:00
|
Nightly build on vauxhall ( x86_64, Fedora 10 ) started at 2009-01-03 03:20:07 GMT 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 == 481 tests, 13 stderr failures, 1 stdout failure, 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) none/tests/res_search (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 == 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) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Sat Jan 3 03:33:44 2009 --- new.short Sat Jan 3 03:48:13 2009 *************** *** 8,10 **** ! == 481 tests, 13 stderr failures, 0 stdout failures, 0 post failures == cachegrind/tests/chdir (stderr) --- 8,10 ---- ! == 481 tests, 13 stderr failures, 1 stdout failure, 0 post failures == cachegrind/tests/chdir (stderr) *************** *** 22,23 **** --- 22,24 ---- none/tests/blockfault (stderr) + none/tests/res_search (stdout) |
|
From: Tom H. <th...@cy...> - 2009-01-03 03:31:56
|
Nightly build on mg ( x86_64, Fedora 9 ) started at 2009-01-03 03:10:05 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) |