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
(11) |
2
(9) |
3
(14) |
4
(18) |
5
(13) |
|
6
(4) |
7
(12) |
8
(16) |
9
(14) |
10
(8) |
11
(9) |
12
(7) |
|
13
(12) |
14
(6) |
15
(14) |
16
(5) |
17
(10) |
18
(8) |
19
(5) |
|
20
(10) |
21
(16) |
22
(5) |
23
(14) |
24
(10) |
25
(11) |
26
(6) |
|
27
(9) |
28
(8) |
29
(11) |
30
(9) |
31
(18) |
|
|
|
From: Nicholas N. <nj...@cs...> - 2008-01-03 23:04:24
|
On Thu, 3 Jan 2008, Russell Sears wrote: > I've attached a patch that adds support for Linux's sync_file_range. I > tested it under x86_64, and added an entry for x86 since I happened to find > the syscall number in my /usr/include directory. Presumably, it's supported > on other architectures too... > > The manpage lists "off64_t" as the type for some of the parameters, but there > is no vki_off64_t type, so I used vki_off_t. Should I use vki_loff_t > instead? If a kernel type isn't present, a vki_* version should be added. See the comment at the top of include/vki/vki-linux.h. But don't trust the man pages, they mostly describe glibc's wrappers for the syscalls. These mostly are the same as the kernel syscalls, but not always. Only trust the kernel code. Unfortunately, I can't remember where in the kernel code the syscall prototypes are defined. Nick |
|
From: <sv...@va...> - 2008-01-03 22:57:20
|
Author: njn Date: 2008-01-03 22:57:18 +0000 (Thu, 03 Jan 2008) New Revision: 350 Log: tweak Modified: trunk/info/platforms.html Modified: trunk/info/platforms.html =================================================================== --- trunk/info/platforms.html 2008-01-03 05:13:42 UTC (rev 349) +++ trunk/info/platforms.html 2008-01-03 22:57:18 UTC (rev 350) @@ -79,7 +79,7 @@ <tr><th> </th> <th>Linux</th> <th>*BSD</th> <th>Darwin</th> <th>Solaris</th></tr> <tr><td>x86 </td> <td>done </td> <td>low</td> <td>high</td> <td>low</td></tr> <tr><td>amd64</td> <td>done </td> <td>low</td> <td>eventually?</td> <td></td></tr> -<tr><td>ppc32</td> <td>done </td> <td></td> <td>high</td> <td></td></tr> +<tr><td>ppc32</td> <td>done </td> <td></td> <td>low</td> <td></td></tr> <tr><td>ppc64</td> <td>done </td> <td></td> <td>?</td> <td></td></tr> <tr><td>arm </td> <td>low </td> <td></td> <td></td> <td></td></tr> <tr><td>mips </td> <td>low </td> <td></td> <td></td> <td></td></tr> |
|
From: Russell S. <se...@cs...> - 2008-01-03 22:53:28
|
I've attached a patch that adds support for Linux's sync_file_range. I tested it under x86_64, and added an entry for x86 since I happened to find the syscall number in my /usr/include directory. Presumably, it's supported on other architectures too... The manpage lists "off64_t" as the type for some of the parameters, but there is no vki_off64_t type, so I used vki_off_t. Should I use vki_loff_t instead? Thanks, Rusty |
|
From: <sv...@va...> - 2008-01-03 05:13:39
|
Author: njn Date: 2008-01-03 05:13:42 +0000 (Thu, 03 Jan 2008) New Revision: 349 Log: wibble Modified: trunk/info/priorities.html Modified: trunk/info/priorities.html =================================================================== --- trunk/info/priorities.html 2008-01-03 05:12:10 UTC (rev 348) +++ trunk/info/priorities.html 2008-01-03 05:13:42 UTC (rev 349) @@ -6,9 +6,6 @@ what we think is important, but it should not be taken as inviolable.</p> -<p>Following the goals and rationales are some background comments on -techniques that have been used to achieve these goals.</p> - <h2>High Priority</h2> <ul> @@ -117,8 +114,8 @@ <h2>Example Techniques</h2> -Here are some techniques that in the past have been used to achieve -the above goals. This list does not claim to be complete. +<p>Here are some techniques that in the past have been used to achieve +the above goals. This list does not claim to be complete.</p> <ul> <li> |
|
From: <sv...@va...> - 2008-01-03 05:12:07
|
Author: njn Date: 2008-01-03 05:12:10 +0000 (Thu, 03 Jan 2008) New Revision: 348 Log: tweaks Modified: trunk/info/priorities.html Modified: trunk/info/priorities.html =================================================================== --- trunk/info/priorities.html 2008-01-03 05:09:36 UTC (rev 347) +++ trunk/info/priorities.html 2008-01-03 05:12:10 UTC (rev 348) @@ -155,9 +155,10 @@ <li> Valgrind serialises thread execution. For subtle atomicity reasons, -this is necessary for tools (like Memcheck) that use shadow values. It -means they can not use more than one processor at a time on -multiprocessor machines. +this is necessary for tools (like Memcheck) that use shadow values. +(How to do a better job with this is still an open research question.) +It means that Valgrind tools can not use more than one processor at a +time on multiprocessor machines. </li> <li> |
|
From: <sv...@va...> - 2008-01-03 05:09:33
|
Author: njn Date: 2008-01-03 05:09:36 +0000 (Thu, 03 Jan 2008) New Revision: 347 Log: more html fixes Modified: trunk/info/priorities.html Modified: trunk/info/priorities.html =================================================================== --- trunk/info/priorities.html 2008-01-03 05:03:22 UTC (rev 346) +++ trunk/info/priorities.html 2008-01-03 05:09:36 UTC (rev 347) @@ -50,6 +50,7 @@ </li> </ul> + <h2>Medium Priority</h2> <ul> @@ -83,13 +84,15 @@ techniques. <p><em>Platform-specific techniques and assumptions are clearly a - hindrance to portablility. We have also found them to sometimes - reduce stability.</em></p> +hindrance to portablility. We have also found them to sometimes reduce +stability.</em></p> </li> </ul> + <h2>Low Priority</h2> +<ul> <li> <p><strong>Performance of lightweight tools.</strong></p> @@ -117,6 +120,7 @@ Here are some techniques that in the past have been used to achieve the above goals. This list does not claim to be complete. +<ul> <li> Valgrind's code representation (IR) favours powerful instrumentation capabilities. This allows heavyweight tools such as Memcheck to be |
|
From: <sv...@va...> - 2008-01-03 05:03:20
|
Author: njn Date: 2008-01-03 05:03:22 +0000 (Thu, 03 Jan 2008) New Revision: 346 Log: fix tags Modified: trunk/info/priorities.html Modified: trunk/info/priorities.html =================================================================== --- trunk/info/priorities.html 2008-01-03 05:01:50 UTC (rev 345) +++ trunk/info/priorities.html 2008-01-03 05:03:22 UTC (rev 346) @@ -79,7 +79,7 @@ </li> <li> -<p><strong>Portability.<strong> We want to avoid platform-specific +<p><strong>Portability.</strong> We want to avoid platform-specific techniques. <p><em>Platform-specific techniques and assumptions are clearly a @@ -91,7 +91,7 @@ <h2>Low Priority</h2> <li> -<p><strong>Performance of lightweight tools.<strong></p> +<p><strong>Performance of lightweight tools.</strong></p> <p><em>Heavyweight tools are both harder to construct and more valuable to users than simple ones (eg, instruction counters, memory trace |
|
From: <sv...@va...> - 2008-01-03 05:01:47
|
Author: njn Date: 2008-01-03 05:01:50 +0000 (Thu, 03 Jan 2008) New Revision: 345 Log: Add a page about development priorities that Julian and I wrote ages ago. Currently not linked to from the front page -- I'm still not sure if we should put it up. Added: trunk/info/priorities.html Added: trunk/info/priorities.html =================================================================== --- trunk/info/priorities.html (rev 0) +++ trunk/info/priorities.html 2008-01-03 05:01:50 UTC (rev 345) @@ -0,0 +1,171 @@ +<h1>Development Priorities</h1> + +<p>The following is a prioritised list of Valgrind design and +development goals. Each one is followed by a rationale written <em>like +this</em>. The aim of this list is to give a general understanding of +what we think is important, but it should not be taken as +inviolable.</p> + +<p>Following the goals and rationales are some background comments on +techniques that have been used to achieve these goals.</p> + +<h2>High Priority</h2> + +<ul> +<li> +<p><strong>Robustness.</strong> Valgrind should be able to correctly run +as many programs as possible on the platforms we support.</p> + +<p><em>Systems which cannot be relied on to handle the vast majority of +presented workloads soon fall out of favour with users.</em></p> +</li> + +<li> +<p><strong>Accuracy of outputs.</strong> Debugging and profiling +information generated by the tools should be sufficiently accurate as to +be both useful to and credible to users. For example, bug detectors +should have minimal false positives.</p> + +<p><em>Tools which produce unreliable or non-credible results soon fall +out of favour with users.</em></p> +</li> + +<li> +<p><strong>Design simplicity.</strong> The design and implementation +should be easy to understand, maintain, test and verify.</p> + +<p><em>Our engineering resources are very limited, so the code base +should be structured to make best use of them. Also, a simple code base +is more accessible to newcomers.</em></p> +</li> + +<li> +<p><strong>Instrumentation capabilities.</strong> Firstly, provide +enough capabilities to keep Memcheck going. Then add capabilities as +required by other tools.</p> + +<p><em>We aim for Valgrind to be an effective framework for building +dynamic analysis tools, so it needs to provide instrumentation +capabilities as required by current and emerging tools.</em></p> +</li> +</ul> + +<h2>Medium Priority</h2> + +<ul> +<li> +<p><strong>Performance (speed and memory usage) of heavyweight +tools.</strong> This covers the speed of both the Valgrind core and the +tool components.</p> + +<p><em>All else being equal, faster and less space hungry tools are able +to handle larger workloads and so are more useful.</em></p> +</li> + +<li> +<p><strong>Usability.</strong> Users should be able to use the tools +without excessive complication or inconvenience.</p> + +<p><em>Tools which are difficult or inconvenient to use soon fall out of +favour with users.</em></p> +</li> + +<li> +<p><strong>New tools.</strong> Encourage development of new tools as +needs and opportunities develop.</p> + +<p><em>The needs of users and the general computing landscape changes +slowly over time, and it is important to remain relevant.</em></p> +</li> + +<li> +<p><strong>Portability.<strong> We want to avoid platform-specific +techniques. + +<p><em>Platform-specific techniques and assumptions are clearly a + hindrance to portablility. We have also found them to sometimes + reduce stability.</em></p> +</li> +</ul> + +<h2>Low Priority</h2> + +<li> +<p><strong>Performance of lightweight tools.<strong></p> + +<p><em>Heavyweight tools are both harder to construct and more valuable +to users than simple ones (eg, instruction counters, memory trace +generators), and other instrumentation frameworks (such as Pin and +DynamoRIO) support lightweight tools well. Where design choices +conflict they have usually been resolved in favour of supporting +heavyweight tools better.</em></p> +</li> + +<li> +<p><strong>New platforms.</strong> Although we want portability, we +don't want to support a lot of platforms, because it's hard work, +especially to do it to a high quality.</p> + +<p><em>As above, our engineering resources are limited and so we should +focus effort on the most widely used platforms.</em> +</li> + +</ul> + + +<h2>Example Techniques</h2> +Here are some techniques that in the past have been used to achieve +the above goals. This list does not claim to be complete. + +<li> +Valgrind's code representation (IR) favours powerful instrumentation +capabilities. This allows heavyweight tools such as Memcheck to be +built and have reasonable performance. However, it gives poor +performance for lightweight tools such as trace collectors. Such +lightweight tools will have better performance if written in other DBI +frameworks such as Pin or DynamoRIO. +</li> + +<li> +Valgrind does not use libc or any other library itself. This used to +not be true, but it caused robustness and portability problems. +</li> + +<li> +Valgrind makes very few assumptions about memory layout. This used to +not be true, but it caused robustness and portability problems. For +example, Memcheck's two-level shadow memory representation means its +shadow memory can be laid out very flexibly, but it is not particularly +fast. A "half-and-half" representation that stores shadow memory can be +faster, but fails on some programs, some Linux kernel configurations, +and is incompatible with other OSes such as Mac OS X. +</li> + +<li> +Valgrind used to use x86 segmentation to prevent a client program from +accidentally clobbering Valgrind data. However, this is not portable to +other platforms, and it was removed once support for other platforms was +added. Having such platform-specific features hinders portability and +makes testing harder. +</li> + +<li> +Valgrind serialises thread execution. For subtle atomicity reasons, +this is necessary for tools (like Memcheck) that use shadow values. It +means they can not use more than one processor at a time on +multiprocessor machines. +</li> + +<li> +Assertions and sanity checks. The code base contains a large number of +assertions. Additionally, many subsystems have sanity check code which +periodically checks important data structures in detail. In some cases +these checkers are permanently enabled, even at the cost of some +performance. These include: the IR intermediate representation, the +address space manager (m_aspacemgr), the translation table manager +(m_transtab), some parts of Memcheck. One side effect is that Valgrind +almost never segfaults - instead if it fails it does so by failing one +of these assertions or sanity checks. +</li> + +</ul> |
|
From: <sv...@va...> - 2008-01-03 04:41:51
|
Author: njn Date: 2008-01-03 04:41:54 +0000 (Thu, 03 Jan 2008) New Revision: 344 Log: Add missing tag. Modified: trunk/info/about.html Modified: trunk/info/about.html =================================================================== --- trunk/info/about.html 2008-01-03 00:44:09 UTC (rev 343) +++ trunk/info/about.html 2008-01-03 04:41:54 UTC (rev 344) @@ -43,7 +43,7 @@ have had feedback from users working on projects with up to 25 million lines of code. It has been used on projects of all sizes, from single-user personal projects, to projects with hundreds of -programmers. +programmers.</li> <li>Valgrind is suitable for any type of software. Valgrind has been used with desktop applications, libraries, databases, games, web |
|
From: Tom H. <th...@cy...> - 2008-01-03 04:01:00
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2008-01-03 03:15:04 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 323 tests, 66 stderr failures, 1 stdout failure, 28 post failures == memcheck/tests/addressable (stderr) memcheck/tests/badjump (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/erringfds (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-pool-0 (stderr) memcheck/tests/leak-pool-1 (stderr) memcheck/tests/leak-pool-2 (stderr) memcheck/tests/leak-pool-3 (stderr) memcheck/tests/leak-pool-4 (stderr) memcheck/tests/leak-pool-5 (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/long_namespace_xml (stderr) memcheck/tests/lsframe1 (stderr) memcheck/tests/lsframe2 (stderr) memcheck/tests/malloc_free_fill (stderr) memcheck/tests/match-overrun (stderr) memcheck/tests/noisy_child (stderr) memcheck/tests/partial_load_dflt (stderr) memcheck/tests/partial_load_ok (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigkill (stderr) memcheck/tests/stack_changes (stderr) memcheck/tests/supp_unknown (stderr) memcheck/tests/x86/bug152022 (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/xor-undef-x86 (stderr) memcheck/tests/xml1 (stderr) massif/tests/alloc-fns-A (post) massif/tests/alloc-fns-B (post) massif/tests/basic (post) massif/tests/basic2 (post) massif/tests/big-alloc (post) massif/tests/culling1 (stderr) massif/tests/culling2 (stderr) massif/tests/custom_alloc (post) massif/tests/deep-A (post) massif/tests/deep-B (stderr) massif/tests/deep-B (post) massif/tests/deep-C (stderr) massif/tests/deep-C (post) massif/tests/deep-D (post) massif/tests/ignoring (post) massif/tests/insig (post) massif/tests/long-time (post) massif/tests/new-cpp (post) massif/tests/null (post) massif/tests/one (post) massif/tests/overloaded-new (post) massif/tests/peak (post) massif/tests/peak2 (stderr) massif/tests/peak2 (post) massif/tests/realloc (stderr) massif/tests/realloc (post) massif/tests/thresholds_0_0 (post) massif/tests/thresholds_0_10 (post) massif/tests/thresholds_10_0 (post) massif/tests/thresholds_10_10 (post) massif/tests/thresholds_5_0 (post) massif/tests/thresholds_5_10 (post) massif/tests/zero1 (post) massif/tests/zero2 (post) none/tests/blockfault (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) helgrind/tests/hg01_all_ok (stderr) helgrind/tests/hg02_deadlock (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/hg06_readshared (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc02_simple_tls (stderr) helgrind/tests/tc03_re_excl (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc07_hbl1 (stderr) helgrind/tests/tc08_hbl2 (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc11_XCHG (stderr) helgrind/tests/tc12_rwl_trivial (stderr) helgrind/tests/tc14_laog_dinphils (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) helgrind/tests/tc24_nonzero_sem (stderr) |
|
From: Tom H. <th...@cy...> - 2008-01-03 03:38:12
|
Nightly build on lloyd ( x86_64, Fedora 7 ) started at 2008-01-03 03:05:10 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 == 357 tests, 7 stderr failures, 2 stdout failures, 0 post failures == memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc22_exit_w_lock (stderr) |
|
From: Tom H. <th...@cy...> - 2008-01-03 03:28:37
|
Nightly build on dellow ( x86_64, Fedora 8 ) started at 2008-01-03 03:10:05 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 == 357 tests, 8 stderr failures, 2 stdout failures, 0 post failures == memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc22_exit_w_lock (stderr) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 357 tests, 8 stderr failures, 4 stdout failures, 0 post failures == memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/pth_cvsimple (stdout) none/tests/pth_detached (stdout) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc22_exit_w_lock (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Thu Jan 3 03:19:28 2008 --- new.short Thu Jan 3 03:28:39 2008 *************** *** 8,10 **** ! == 357 tests, 8 stderr failures, 4 stdout failures, 0 post failures == memcheck/tests/malloc_free_fill (stderr) --- 8,10 ---- ! == 357 tests, 8 stderr failures, 2 stdout failures, 0 post failures == memcheck/tests/malloc_free_fill (stderr) *************** *** 16,19 **** none/tests/mremap2 (stdout) - none/tests/pth_cvsimple (stdout) - none/tests/pth_detached (stdout) helgrind/tests/tc18_semabuse (stderr) --- 16,17 ---- |
|
From: Tom H. <th...@cy...> - 2008-01-03 03:15:26
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2008-01-03 03:00:03 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 == 359 tests, 30 stderr failures, 1 stdout failure, 0 post failures == memcheck/tests/addressable (stderr) memcheck/tests/badjump (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/malloc_free_fill (stderr) memcheck/tests/match-overrun (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/supp_unknown (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/blockfault (stderr) none/tests/fdleak_fcntl (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) helgrind/tests/hg01_all_ok (stderr) helgrind/tests/hg02_deadlock (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc14_laog_dinphils (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) |
|
From: <sv...@va...> - 2008-01-03 00:53:02
|
Author: njn Date: 2008-01-03 00:44:09 +0000 (Thu, 03 Jan 2008) New Revision: 343 Log: Update front page, mostly for 3.3.0 changes. Modified: trunk/index.html Modified: trunk/index.html =================================================================== --- trunk/index.html 2007-12-11 03:10:44 UTC (rev 342) +++ trunk/index.html 2008-01-03 00:44:09 UTC (rev 343) @@ -13,17 +13,18 @@ <p>Valgrind is an <a href="/gallery/awards.html">award-winning</a> -suite of tools for debugging and profiling Linux -programs. With the tools that come with Valgrind, you can -automatically detect many memory management and threading bugs, -avoiding hours of frustrating bug-hunting, making your programs -more stable. You can also perform detailed profiling, to speed up -and reduce memory use of your programs.</p> +instrumentation framework for building dynamic analysis tools. There +are Valgrind tools that can automatically detect many memory management +and threading bugs, and profile your programs in detail. You can also +use Valgrind to build new tools. +</p> -<p>The Valgrind distribution currently includes four tools: a -memory error detector, a cache (time) profiler, a call-graph profiler, -and a heap (space) profiler. It runs on the following platforms: -X86/Linux, AMD64/Linux, PPC32/Linux, PPC64/Linux.</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>Valgrind is <a href="http://www.opensource.org/">Open Source</a> / <a href="http://www.gnu.org/philosophy/free-sw.html">Free Software</a>, @@ -42,15 +43,6 @@ for x86/Linux, AMD64/Linux, PPC32/Linux and PPC64/Linux, is available. (<a href="/docs/manual/dist.news.html">release notes</a>). </p></li> - - <li><p>January 29 2007: valgrind-3.2.3, - for x86/Linux, AMD64/Linux, PPC32/Linux and PPC64/Linux, is available. - 3.2.3 is almost identical to 3.2.2, but fixes a regression that - unfortunately crept into 3.2.2.</p></li> - - <li><p>October 30 2006: The slides for a tutorial entitled "Building - Workload Characterization Tools with Valgrind" are available on the - <a href="/docs/pubs.html">publications page</a>.</p></li> </ul> <br /> |