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
(6) |
2
(4) |
3
(12) |
4
(14) |
5
(6) |
|
6
(1) |
7
(10) |
8
(4) |
9
(1) |
10
(2) |
11
(7) |
12
(1) |
|
13
(3) |
14
(8) |
15
(5) |
16
(6) |
17
(1) |
18
(11) |
19
(5) |
|
20
(2) |
21
(7) |
22
(3) |
23
(1) |
24
|
25
(4) |
26
(1) |
|
27
(1) |
28
|
29
(1) |
30
(7) |
|
|
|
|
From: Alexander P. <gl...@go...> - 2009-09-11 13:43:16
|
Nightly build on mcgrind ( Darwin 9.7.0 i386 ) Started at 2009-09-11 15:06:01 MSD Ended at 2009-09-11 15:24:58 MSD 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 == 433 tests, 22 stderr failures, 1 stdout failure, 0 post failures == memcheck/tests/null_socket (stdout) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/varinfo1 (stderr) memcheck/tests/varinfo2 (stderr) memcheck/tests/varinfo3 (stderr) memcheck/tests/varinfo4 (stderr) memcheck/tests/varinfo5 (stderr) memcheck/tests/varinfo6 (stderr) none/tests/async-sigs (stderr) none/tests/faultstatus (stderr) none/tests/pth_blockedsig (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/rwlock_race (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc23_bogus_condwait (stderr) -- Alexander Potapenko Software Engineer Google Moscow |
|
From: Stanislav S.
|
On Fri, 11 Sep 2009 22:06:38 +1000 Nicholas Nethercote <n.n...@gm...> mentioned: > On Fri, Sep 11, 2009 at 6:35 PM, Stanislav Sedov <st...@fr...> wrote: > > On Fri, 4 Sep 2009 22:22:25 +0400 > > Stanislav Sedov <stas@FreeBSD.org> mentioned: > > > >> Hi, guys! > >> > >> As you might know there has been work going on in the FreeBSD > >> community to port Valgrind to FreeBSD OS. Currently thanks to > >> efforts of a lot of developers we have a working preliminary > >> port done. Althought a lot of work has to be done yet, it is > >> in a good shape now and fairly usable on both amd64 and i386 > >> platforms. > >> > >> I'd love to work with someone from the community on integrating > >> our patches to the main tree to avoid excessive merge conflicts > >> in the future. There have been a lot of changes so that work > >> will require a good amount of time and coordination. > >> > >> Is it possible? How do we proceed? > >> > >> Let me know your thoughts. > >> > > > > So, is anyone interested? Where I should submit patches to? > > http://www.valgrind.org/info/platforms.html gives our general view on ports.. > > In short, Valgrind ports are, as you say, a great deal of work. The > recent Darwin port represented years of work. And the audience for a > *BSD port is greatly smaller than Darwin. So the cost/benefit ratio > doesn't look very good. > Nicholas, as I outlined in the original email we have the perliminary port done. It is currently available in the FreeBSD ports collection, but supporting internal fork of valgrind project seems to me not the best way to go. There will be operational costs needed to integrate our patches into the three, but I don't think they will be *too* high. Target audience is questionable, but note that FreeBSD is heavily used as server OS where server applications get profiled and where darwin is not widely used. Let me know your thoughts. Thanks! -- Stanislav Sedov ST4096-RIPE |
|
From: Nicholas N. <n.n...@gm...> - 2009-09-11 12:06:48
|
On Fri, Sep 11, 2009 at 6:35 PM, Stanislav Sedov <st...@fr...> wrote: > On Fri, 4 Sep 2009 22:22:25 +0400 > Stanislav Sedov <stas@FreeBSD.org> mentioned: > >> Hi, guys! >> >> As you might know there has been work going on in the FreeBSD >> community to port Valgrind to FreeBSD OS. Currently thanks to >> efforts of a lot of developers we have a working preliminary >> port done. Althought a lot of work has to be done yet, it is >> in a good shape now and fairly usable on both amd64 and i386 >> platforms. >> >> I'd love to work with someone from the community on integrating >> our patches to the main tree to avoid excessive merge conflicts >> in the future. There have been a lot of changes so that work >> will require a good amount of time and coordination. >> >> Is it possible? How do we proceed? >> >> Let me know your thoughts. >> > > So, is anyone interested? Where I should submit patches to? http://www.valgrind.org/info/platforms.html gives our general view on ports. In short, Valgrind ports are, as you say, a great deal of work. The recent Darwin port represented years of work. And the audience for a *BSD port is greatly smaller than Darwin. So the cost/benefit ratio doesn't look very good. Nick |
|
From: Stanislav S.
|
On Fri, 4 Sep 2009 22:22:25 +0400 Stanislav Sedov <stas@FreeBSD.org> mentioned: > Hi, guys! > > As you might know there has been work going on in the FreeBSD > community to port Valgrind to FreeBSD OS. Currently thanks to > efforts of a lot of developers we have a working preliminary > port done. Althought a lot of work has to be done yet, it is > in a good shape now and fairly usable on both amd64 and i386 > platforms. > > I'd love to work with someone from the community on integrating > our patches to the main tree to avoid excessive merge conflicts > in the future. There have been a lot of changes so that work > will require a good amount of time and coordination. > > Is it possible? How do we proceed? > > Let me know your thoughts. > So, is anyone interested? Where I should submit patches to? -- Stanislav Sedov ST4096-RIPE |
|
From: Nicholas N. <n.n...@gm...> - 2009-09-11 05:14:06
|
2009/9/10 Mathias Fröhlich <M.F...@sc...>: > > I have done a small valgrind tool that tests each result of a floating point > operation agains inf and nan values. > > I have written that tool to find problems in some simulation codes at a > customer here. Also I used that last weekend to find similar problems in > Flightgear (an open source flight simulation). > So one might ask if the work of this tool could be done by the usual floating > point traps. > The problem with the hardware traps is that they are asyncronous. That means > you get them a little later than when the problem happens - I believe at the > next fpu instruction past the error. Which means that you sometimes get a > usable hint where the problem is but sometomes you get signaled somewhere > completely different. > > That tool prooved to be much more useful since it really points you to the > *exact* source code line where the problem happens. > > I would like to know if there is any chance to get such a tool into the public > valgrind tree. > And if so, what to do to get that stuff reviewed, contributed ... It does sound like a useful tool. Probably the best thing is to file a bug and attach the patch, see http://www.valgrind.org/support/features.html. It's possible that it could end up in the public Valgrind tree. Some prerequisites for that: - the code must be of sufficient quality - there must be good tests and documentation - it should be demonstrably useful (testimony from others would be useful) - you must be willing to maintain it. Nick |
|
From: Nicholas N. <n.n...@gm...> - 2009-09-11 05:11:30
|
On Fri, Sep 11, 2009 at 3:05 PM, chenping19850429 <che...@16...> wrote: > Hi, > > I notice the record & replay tool on Valgrind: > > http://article.gmane.org/gmane.comp.debugging.valgrind.devel/5116/match=record+replay > > and I find it is a very interesting tool. > > What about the current progress of this tool? Does it keep maintained? I don't know. I had a look at it a while back, it seemed like a promising prototype, but would need a lot of work to be made into something robust. > From the maillist, I notice that the tools can record the non-determinism > information of the program, and replay it. However, I confused by the > following question: > > (1) Does it record all the instructions when the program is running? If > not, except the non-determinism information, does it record other > information such as the environment information? I think it just records non-deterministic things like system call results. > (2) Can extend the tool to be a checkpoint/replay tool? That is to say, I > can set some checkpoint when program is running, and when it fails, I can > select the correct point, and replay it from that point? I don't know about that. Nick |
|
From: chenping19850429 <che...@16...> - 2009-09-11 05:06:15
|
Hi, I notice the record & replay tool on Valgrind: http://article.gmane.org/gmane.comp.debugging.valgrind.devel/5116/match=record+replay and I find it is a very interesting tool. What about the current progress of this tool? Does it keep maintained? From the maillist, I notice that the tools can record the non-determinism information of the program, and replay it. However, I confused by the following question: (1) Does it record all the instructions when the program is running? If not, except the non-determinism information, does it record other information such as the environment information? (2) Can extend the tool to be a checkpoint/replay tool? That is to say, I can set some checkpoint when program is running, and when it fails, I can select the correct point, and replay it from that point? Thanks Chen Ping |