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
(9) |
2
(16) |
|
3
(9) |
4
(8) |
5
(9) |
6
(10) |
7
(14) |
8
(10) |
9
(7) |
|
10
(14) |
11
(19) |
12
(22) |
13
(18) |
14
(20) |
15
(10) |
16
(12) |
|
17
(13) |
18
(7) |
19
(12) |
20
(13) |
21
(9) |
22
(12) |
23
(6) |
|
24
(5) |
25
(5) |
26
(6) |
27
(7) |
28
(9) |
29
(13) |
30
(21) |
|
From: Nicholas N. <nj...@cs...> - 2006-09-04 21:19:41
|
On Mon, 4 Sep 2006, Tony Reix wrote: > Two years ago, we had studied Valgrind/Helgrind. > Our conclusion was that it was not the perfect solution for helping > these kinds of users: NPTL maintainers, and Linux customers support. > > If I remember well, Helgrind provides its own thread library. So it > helps to find some kinds of bugs, but it cannot help in many complex > cases related to NPTL details. That was true then, but Valgrind now doesn't replace the native thread library. > So, we developed a tool named PTT (NPTL POSIX Trace Tool), aimed at > providing a trace tool integrated into the NPTL library, with the lowest > impact to performance and behavior as possible. It also provides some > performance information related to contention. > PTT is available at: > http://sourceforge.net/projects/nptltracetool > http://nptltracetool.sourceforge.net/ > (See OLS'05 for a paper describing PTT. Or read the up-to-date > documentation on these sites). > PTT has been built by several students working at Bull labs since 2004 > and is fully Open Source. > [...] > So, if Valgrind developers are interested by PTT and would like either > to add it to the Valgrind's Tool Suite or to mix it with the Helgrind > tool, that would be very nice and very useful for the Linux community, I > think. It looks like an interesting tools, but I don't see why it should be part of the Valgrind distribution. If it was built with Valgrind, maybe, but it seems to be unrelated apart from involving debugging. Nick |
|
From: Julian S. <js...@ac...> - 2006-09-04 20:41:03
|
> data races. E.g. the ThreadChecker that is part of Intel VTune reports the
> complete call stack for both first and second accesses involved in a data
> race. The granularity of this information is one source line: an overview
Is the following a useful idea? It would give a complete call stack for
the second access in each data race and requires acceptable memory overhead.
All assuming there are no flaws in the idea.
-------
First, forget about the suggestion I made previously in this thread.
The following builds on the vanilla drd implementation that already
exists.
We can take advantage of the fact that V only allows one thread to run
at any time. When a thread is scheduled for execution, compute a
"danger set". This is the set of memory locations accessed by the
union of segments which are unordered relative to the segment which is
about to be scheduled. (ie, the usual deal).
As the segment runs, check each load and store against the danger set.
If the load/store addresses exist in the danger set, we know that the
standard drd algorithm will eventually flag them as race addresses.
So we might as well print a backtrace right now; then at least we will
know the backtrace of this second access.
In short the idea is to do the segment comparison incrementally, rather
than wait until segment completion, as in the current implementation.
This is possible because V's one-thread-at-a-time means only one
segment is ever changing at any one time.
The overheads are:
(1) for each load and store, not only do we need to mark the current
segment's bitmaps; now we also need to check the danger set too.
Not great, but tolerable.
(2) for each thread scheduling, need to construct the danger set.
Could possibly be optimised; eg if a thread repeatedly stops for
(eg) syscalls and then resumes, and no other thread runs in between,
can reuse existing danger set.
(3) Extra space required to store the danger set.
So the question is, will it work, or did I miss something?
Consider two segments, A and B, both available to run, not ordered, and
containing a conflicting address. Does the scheme guarantee still to
detect the conflict? I believe so.
- Suppose the scheduling is such that A visits the conflicting address
X for the first time before B does. Then, for all subsequent
scheduling(s) of B, X will be in the danger-set for B; hence if
B accesses X then the conflict will be found.
- Same argument the other way round if B visits the conflicting address
first.
Suppose A visits the conflicting address first, but there is a synchronising
event between A and B before B visits that address for the first time.
Then A and B acquire an ordering (A < B), so A's accesses are no longer
included in B's danger set, and so no conflict is reported (which is correct;
there is no race). Of course this is just a restatement of the normal Diota
algorithm; it is not unique to the suggested modification.
J
|
|
From: Tony R. <ton...@bu...> - 2006-09-04 13:07:44
|
Hello, Two years ago, we had studied Valgrind/Helgrind. Our conclusion was that it was not the perfect solution for helping these kinds of users: NPTL maintainers, and Linux customers support. If I remember well, Helgrind provides its own thread library. So it helps to find some kinds of bugs, but it cannot help in many complex cases related to NPTL details. So, we developed a tool named PTT (NPTL POSIX Trace Tool), aimed at providing a trace tool integrated into the NPTL library, with the lowest impact to performance and behavior as possible. It also provides some performance information related to contention. PTT is available at: http://sourceforge.net/projects/nptltracetool http://nptltracetool.sourceforge.net/ (See OLS'05 for a paper describing PTT. Or read the up-to-date documentation on these sites). PTT has been built by several students working at Bull labs since 2004 and is fully Open Source. PTT is now mature and is easy to use by end-users. It comes with documentation and has been ported/tested on ia32, x86_64, ppc (still bugs ...) and on medium/large multi-processor machines. It has been tested with OPTS and some other applications (Java, HPC). PTT could also be added to glibc by distributions: it generates an unmodified version of the glibc and a separate version of glibc enabling to generate traces. And one can move from one library to the other very easily. But the best solution would be to have it added to the glibc sources. it would be a matter of hours to add it. Discussions with glibc maintainers (Ulrich Drepper !!) have failed. These guys do not seem to add a debug tool inside the glibc ... Probably they do not know what "customer" and "support" mean. My opinion is that the number of multi-threaded applications will increase quickly now due to the availability of multi-core processors. Since multi-threading is so complex, tools are needed. So, if Valgrind developers are interested by PTT and would like either to add it to the Valgrind's Tool Suite or to mix it with the Helgrind tool, that would be very nice and very useful for the Linux community, I think. The main 4 values of PTT source code are: - its ability to integrated smoothly within glibc source code, - the trace points which required a lot of study to define, - the motor and buffer aimed at not slowing down applications, - the integration within NPTL. (The best solution is still to convince the glibc maintainers to accept PTT. But, after several tries, I have no more hope ... However, once SystemTap offers user-land hooks and is widely accepted by the community, I guess they will have to change their mind and to accept debug/trace tools.) Some people working in Linux RT are interested by an extension of PTT to RT, but I've had no news since months ... Your opinion ? Tony |
|
From: Tom H. <th...@cy...> - 2006-09-04 03:12:31
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2006-09-04 03:00:02 BST 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 == 268 tests, 6 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/mempool (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/fdleak_fcntl (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/tls (stdout) |
|
From: Tom H. <to...@co...> - 2006-09-04 02:45:40
|
Nightly build on dunsmere ( athlon, Fedora Core 5 ) started at 2006-09-04 03:30:05 BST 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 == 239 tests, 5 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2006-09-04 02:25:20
|
Nightly build on dellow ( x86_64, Fedora Core 5 ) started at 2006-09-04 03:10:06 BST 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 == 266 tests, 4 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/mempool (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2006-09-04 02:24:28
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2006-09-04 03:15:01 BST Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Last 20 lines of verbose log follow echo /tmp/ccZIBIyA.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccZIBIyA.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccZIBIyA.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccZIBIyA.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccZIBIyA.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccZIBIyA.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccZIBIyA.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccZIBIyA.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 rm insn_mmx.c insn_sse2.c insn_fpu.c insn_mmxext.c insn_sse.c insn_sse3.c insn_cmov.c insn_basic.c make[5]: Leaving directory `/tmp/valgrind.13807/valgrind/none/tests/x86' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/tmp/valgrind.13807/valgrind/none/tests/x86' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/tmp/valgrind.13807/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/valgrind.13807/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.13807/valgrind' make: *** [check] Error 2 ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Last 20 lines of verbose log follow echo /tmp/ccxoZOQV.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccxoZOQV.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccxoZOQV.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccxoZOQV.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccxoZOQV.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccxoZOQV.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccxoZOQV.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccxoZOQV.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 rm insn_mmx.c insn_sse2.c insn_fpu.c insn_mmxext.c insn_sse.c insn_sse3.c insn_cmov.c insn_basic.c make[5]: Leaving directory `/tmp/valgrind.13807/valgrind/none/tests/x86' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/tmp/valgrind.13807/valgrind/none/tests/x86' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/tmp/valgrind.13807/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/valgrind.13807/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.13807/valgrind' make: *** [check] Error 2 ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Mon Sep 4 03:19:37 2006 --- new.short Mon Sep 4 03:24:18 2006 *************** *** 7,16 **** Last 20 lines of verbose log follow echo ! /tmp/ccxoZOQV.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccxoZOQV.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccxoZOQV.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccxoZOQV.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccxoZOQV.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccxoZOQV.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccxoZOQV.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccxoZOQV.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 --- 7,16 ---- Last 20 lines of verbose log follow echo ! /tmp/ccZIBIyA.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccZIBIyA.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccZIBIyA.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccZIBIyA.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccZIBIyA.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccZIBIyA.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccZIBIyA.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccZIBIyA.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 |
|
From: Tom H. <th...@cy...> - 2006-09-04 02:19:42
|
Nightly build on lloyd ( x86_64, Fedora Core 3 ) started at 2006-09-04 03:05:04 BST 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 == 266 tests, 6 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/leakotron (stdout) memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |