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
(4) |
2
(17) |
3
(9) |
4
(14) |
5
(10) |
6
(11) |
7
(8) |
|
8
(9) |
9
(11) |
10
(29) |
11
(27) |
12
(29) |
13
(36) |
14
(8) |
|
15
(18) |
16
(30) |
17
(25) |
18
(6) |
19
(16) |
20
(13) |
21
(10) |
|
22
(16) |
23
(7) |
24
(8) |
25
(13) |
26
(14) |
27
(14) |
28
(5) |
|
29
(6) |
30
(21) |
31
(14) |
|
|
|
|
|
From: Nicholas N. <n.n...@gm...> - 2009-03-08 22:01:25
|
Hi, The LLVM project has an as-yet-nameless static analysis tool which I just tried on Valgrind. It found 153 things to complain about; this was on the DARWIN branch on my Mac (which I did because there was a precompiled binary for Mac). I downloaded it from here: http://clang.llvm.org/StaticAnalysis.html (the site seems to be down at the moment, though). Here are the steps I used: autogen.sh /path/to/scan-build configure --prefix=`pwd`/inst /path/to/scan-build -o checker-results make This put the results in the directory checker-results (by default they go to /tmp, which is odd). I would have attached the results to this email, but they are 132MB, because the output is lots of pretty HTML files. I've looked through a few but not all of the complaints. 143 of them are dead initialisation/assignment/stores. 10 are logic errors (null deref, undefined deref, undefined return value). It looks like there are some false positives, but some of them are certainly real and worth fixing. The output is quite readable -- sometimes the problem paths go through multiple conditionals before reaching the problem point. I'll look through them in more detail over the next few days, but if anyone else wants to try it might be illuminating. Nick |
|
From: Nicholas N. <n.n...@gm...> - 2009-03-08 20:59:32
|
[Sorry, I forgot to CC the list the first time] On Mon, Mar 9, 2009 at 5:50 AM, <san...@gm...> wrote: > Hi, > > I have just started using Valgrind, it's a fantastic tool! > > Among other things, I am concerned about potential floating > exceptions, so I set an adequate mask. The point is that most of the > operations that raise a FPE when executing normally, do not raise it > when executing through Valgrind. I found no info about it, so I do not > know if that is the intended behaviour (which I guess is not very > desirable). When using Valgrind, NaNs, infs, underflows, etc., wander > around like happy beasts. The FP limitations are in the manual: http://www.valgrind.org/docs/manual/manual-core.html#manual-core.limits : As of version 3.0.0, Valgrind has the following limitations in its implementation of x86/AMD64 floating point relative to IEEE754. Precision: There is no support for 80 bit arithmetic. Internally, Valgrind represents all such "long double" numbers in 64 bits, and so there may be some differences in results. Whether or not this is critical remains to be seen. Note, the x86/amd64 fldt/fstpt instructions (read/write 80-bit numbers) are correctly simulated, using conversions to/from 64 bits, so that in-memory images of 80-bit numbers look correct if anyone wants to see. The impression observed from many FP regression tests is that the accuracy differences aren't significant. Generally speaking, if a program relies on 80-bit precision, there may be difficulties porting it to non x86/amd64 platforms which only support 64-bit FP precision. Even on x86/amd64, the program may get different results depending on whether it is compiled to use SSE2 instructions (64-bits only), or x87 instructions (80-bit). The net effect is to make FP programs behave as if they had been run on a machine with 64-bit IEEE floats, for example PowerPC. On amd64 FP arithmetic is done by default on SSE2, so amd64 looks more like PowerPC than x86 from an FP perspective, and there are far fewer noticeable accuracy differences than with x86. Rounding: Valgrind does observe the 4 IEEE-mandated rounding modes (to nearest, to +infinity, to -infinity, to zero) for the following conversions: float to integer, integer to float where there is a possibility of loss of precision, and float-to-float rounding. For all other FP operations, only the IEEE default mode (round to nearest) is supported. Numeric exceptions in FP code: IEEE754 defines five types of numeric exception that can happen: invalid operation (sqrt of negative number, etc), division by zero, overflow, underflow, inexact (loss of precision). For each exception, two courses of action are defined by IEEE754: either (1) a user-defined exception handler may be called, or (2) a default action is defined, which "fixes things up" and allows the computation to proceed without throwing an exception. Currently Valgrind only supports the default fixup actions. Again, feedback on the importance of exception support would be appreciated. When Valgrind detects that the program is trying to exceed any of these limitations (setting exception handlers, rounding mode, or precision control), it can print a message giving a traceback of where this has happened, and continue execution. This behaviour used to be the default, but the messages are annoying and so showing them is now disabled by default. Use --show-emwarns=yes to see them. The above limitations define precisely the IEEE754 'default' behaviour: default fixup on all exceptions, round-to-nearest operations, and 64-bit precision. Nick |
|
From: <sv...@va...> - 2009-03-08 19:18:37
|
Author: bart
Date: 2009-03-08 19:18:21 +0000 (Sun, 08 Mar 2009)
New Revision: 9328
Log:
Reverted last commit (r9326) -- its commit message did not make sense.
Modified:
trunk/drd/tests/linuxthreads_det.c
Modified: trunk/drd/tests/linuxthreads_det.c
===================================================================
--- trunk/drd/tests/linuxthreads_det.c 2009-03-08 19:03:24 UTC (rev 9327)
+++ trunk/drd/tests/linuxthreads_det.c 2009-03-08 19:18:21 UTC (rev 9328)
@@ -8,18 +8,11 @@
#include <unistd.h>
-static pthread_mutex_t s_mutex;
static pid_t s_main_thread_pid;
void* thread_func(void* arg)
{
- pid_t main_thread_pid;
-
- pthread_mutex_lock(&s_mutex);
- main_thread_pid = s_main_thread_pid;
- pthread_mutex_unlock(&s_mutex);
-
if (s_main_thread_pid == getpid())
{
write(STDOUT_FILENO, "NPTL or non-Linux POSIX threads implementation detected.\n", 57);
@@ -35,15 +28,8 @@
{
pthread_t threadid;
- pthread_mutex_init(&s_mutex, 0);
-
- pthread_mutex_lock(&s_mutex);
s_main_thread_pid = getpid();
- pthread_mutex_unlock(&s_mutex);
pthread_create(&threadid, 0, thread_func, 0);
pthread_join(threadid, 0);
-
- pthread_mutex_destroy(&s_mutex);
-
return 0;
}
|
|
From: <sv...@va...> - 2009-03-08 19:03:36
|
Author: bart Date: 2009-03-08 19:03:24 +0000 (Sun, 08 Mar 2009) New Revision: 9327 Log: Added vgopts: --var-info=yes. Modified: trunk/drd/tests/linuxthreads_det.vgtest Modified: trunk/drd/tests/linuxthreads_det.vgtest =================================================================== --- trunk/drd/tests/linuxthreads_det.vgtest 2009-03-08 19:02:59 UTC (rev 9326) +++ trunk/drd/tests/linuxthreads_det.vgtest 2009-03-08 19:03:24 UTC (rev 9327) @@ -1 +1,2 @@ prog: linuxthreads_det +vgopts: --var-info=yes |
|
From: <sv...@va...> - 2009-03-08 19:03:12
|
Author: bart
Date: 2009-03-08 19:02:59 +0000 (Sun, 08 Mar 2009)
New Revision: 9326
Log:
Fixed another unintended data race.
Modified:
trunk/drd/tests/linuxthreads_det.c
Modified: trunk/drd/tests/linuxthreads_det.c
===================================================================
--- trunk/drd/tests/linuxthreads_det.c 2009-03-08 18:58:06 UTC (rev 9325)
+++ trunk/drd/tests/linuxthreads_det.c 2009-03-08 19:02:59 UTC (rev 9326)
@@ -8,11 +8,18 @@
#include <unistd.h>
+static pthread_mutex_t s_mutex;
static pid_t s_main_thread_pid;
void* thread_func(void* arg)
{
+ pid_t main_thread_pid;
+
+ pthread_mutex_lock(&s_mutex);
+ main_thread_pid = s_main_thread_pid;
+ pthread_mutex_unlock(&s_mutex);
+
if (s_main_thread_pid == getpid())
{
write(STDOUT_FILENO, "NPTL or non-Linux POSIX threads implementation detected.\n", 57);
@@ -28,8 +35,15 @@
{
pthread_t threadid;
+ pthread_mutex_init(&s_mutex, 0);
+
+ pthread_mutex_lock(&s_mutex);
s_main_thread_pid = getpid();
+ pthread_mutex_unlock(&s_mutex);
pthread_create(&threadid, 0, thread_func, 0);
pthread_join(threadid, 0);
+
+ pthread_mutex_destroy(&s_mutex);
+
return 0;
}
|
|
From: <sv...@va...> - 2009-03-08 18:58:23
|
Author: bart
Date: 2009-03-08 18:58:06 +0000 (Sun, 08 Mar 2009)
New Revision: 9325
Log:
Fixed an unintended data race in the bar_trivial test program.
Modified:
trunk/helgrind/tests/bar_trivial.c
Modified: trunk/helgrind/tests/bar_trivial.c
===================================================================
--- trunk/helgrind/tests/bar_trivial.c 2009-03-06 06:12:27 UTC (rev 9324)
+++ trunk/helgrind/tests/bar_trivial.c 2009-03-08 18:58:06 UTC (rev 9325)
@@ -16,7 +16,7 @@
void* child_fn ( void* arg )
{
- long r, n = (long)arg;
+ long r, n = *(long*)arg;
if (n == 1) x++;
@@ -36,12 +36,14 @@
{
long i, r;
pthread_t thr[NTHR];
+ long thread_arg[NTHR];
r = pthread_barrier_init(&bar, NULL, NTHR);
assert(!r);
for (i = 0; i < NTHR; i++) {
- r = pthread_create(&thr[i], NULL, child_fn, (void*)i);
+ thread_arg[i] = i;
+ r = pthread_create(&thr[i], NULL, child_fn, &(thread_arg[i]));
assert(!r);
}
|
|
From: Tom H. <th...@cy...> - 2009-03-08 03:48:21
|
Nightly build on vauxhall ( x86_64, Fedora 10 ) started at 2009-03-08 03:20:05 GMT
Results differ from 24 hours ago
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... done
Running regression tests ... done
Regression test results follow
== 485 tests, 0 stderr failures, 0 stdout failures, 0 post failures ==
=================================================
== 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
== 485 tests, 0 stderr failures, 1 stdout failure, 0 post failures ==
drd/tests/pth_detached2 (stdout)
=================================================
== Difference between 24 hours ago and now ==
=================================================
*** old.short Sun Mar 8 03:34:06 2009
--- new.short Sun Mar 8 03:48:07 2009
***************
*** 4,6 ****
Building valgrind ... done
! Running regression tests ... failed
--- 4,6 ----
Building valgrind ... done
! Running regression tests ... done
***************
*** 8,11 ****
! == 485 tests, 0 stderr failures, 1 stdout failure, 0 post failures ==
! drd/tests/pth_detached2 (stdout)
--- 8,10 ----
! == 485 tests, 0 stderr failures, 0 stdout failures, 0 post failures ==
|
|
From: Tom H. <th...@cy...> - 2009-03-08 03:46:03
|
Nightly build on lloyd ( x86_64, Fedora 7 ) started at 2009-03-08 03:05:09 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 476 tests, 5 stderr failures, 0 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) |
|
From: Tom H. <th...@cy...> - 2009-03-08 03:32:07
|
Nightly build on mg ( x86_64, Fedora 9 ) started at 2009-03-08 03:10: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 == 482 tests, 4 stderr failures, 1 stdout failure, 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) none/tests/linux/mremap2 (stdout) |