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: Bart V. A. <bar...@gm...> - 2006-09-03 18:39:48
|
Being able to record a call stack associated with each load and store would be great. This would allow to report much more precise information about 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 of all data races is displayed in VTune's GUI, and when selecting a data race the source file corresponding to the uppermost stack frame is displayed, and the cursor is positioned on the right source line. On 9/2/06, Julian Seward <js...@ac...> wrote: > > > There's still a way to go, however. I've been thinking about why > drd is difficult to use, what can be done to improve it. [ ... ] > So here's a different impractical idea :-) When drd is recording > races, don't just record the set of read/written addresses, but > something else too: for each written address in the segment, also > record the program counter of the first (or any) writer of that address. > |
|
From: <js...@ac...> - 2006-09-03 04:05:09
|
Nightly build on phoenix ( SuSE 10.0 ) started at 2006-09-03 04:30:01 BST Checking out vex source tree ... done Building vex ... done Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 237 tests, 5 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/leak-tree (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) |
|
From: Tom H. <th...@cy...> - 2006-09-03 03:12:32
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2006-09-03 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-03 02:45:54
|
Nightly build on dunsmere ( athlon, Fedora Core 5 ) started at 2006-09-03 03:30:07 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: Nicholas N. <nj...@cs...> - 2006-09-03 02:37:32
|
On Sat, 2 Sep 2006, Gurganus, Brant L wrote: > It is probably outside the scope of Omega and Memcheck, but there are > resource allocators at higher levels than malloc/free pairs that would be > nice to check, preferrably in an easily extensible fashion. I'd like to > see a way of specifying resource allocators and deallocators that are from > somebody else's code. For example, I'd like a tool that handles finding > unmatched malloc/free, fopen/fclose, open/close, > XOpenDisplay/XCloseDisplay, etc. That's a good idea for a separate tool. I think this would make a great project for someone. I don't think it would be that difficult. I can imagine having a configuration file where you name the alloc/dealloc function pairs. Those examples all follow the following pattern in their type signatures: token alloc(...) ... dealloc(token t) You'd need a way to handle cases where alloc() fails (eg. open() returns -1). You might also need to handle some slight variations on the above (eg. an extra arg to the dealloc function). You'd implement it in Valgrind using function wrapping to know when the alloc/dealloc functions are called. I think Coverity's tools can do this kind of thing, but they use a completely different technique to Valgrind -- static source-level analysis using model checking, as opposed to dynamic binary analysis. Nick |
|
From: Tom H. <th...@cy...> - 2006-09-03 02:25:13
|
Nightly build on dellow ( x86_64, Fedora Core 5 ) started at 2006-09-03 03:10: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, 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: Gurganus, B. L <gur...@ro...> - 2006-09-03 02:24:40
|
It is probably outside the scope of Omega and Memcheck, but there are = resource allocators at higher levels than malloc/free pairs that would = be nice to check, preferrably in an easily extensible fashion. I'd like = to see a way of specifying resource allocators and deallocators that are = from somebody else's code. For example, I'd like a tool that handles = finding unmatched malloc/free, fopen/fclose, open/close, = XOpenDisplay/XCloseDisplay, etc. Brant Gurganus http://www.rose-hulman.edu/~gurganbl -----Original Message----- From: val...@li... on behalf of = Bryan Meredith Sent: Sat 09/02/06 5:41 PM To: val...@li...; = val...@li... Subject: [Valgrind-developers] Omega - Beta 5 Announcement =20 Fellow Valgrinders, please see http://www.brainmurders.eclipse.co.uk/omega.html for a complete overview of what this tool can do for you! (We use this heavily at work - feel free to give it a spin...) >From the web page: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Omega addresses what I perceive to be one of the few shortfalls of the excellent Valgrind Memcheck Tool - where Memcheck reports the location that a leaked block was allocated, Omega also shows where it was leaked. New in Beta5: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Aggregates the circular references together into common contexts, giving a repeat count and leak amount for that context and makes display = optional. Broke the debugger attach :( On the positive side, it gives much more accurate leak reports in some cases, having finally closed off some edge cases with functions that return values. A reported bug with realloc() on x86 (not x86-64) was also fixed (thanks for the report). Exposed some internal sizing information for users with HUGE programs to tweak for potentially faster execution. The next patch is likely to be a release candidate unless you find me some juicy bugs to chomp on. Known Issues: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I have a wrapper around main() to detect when to stop tracking - if you are using threads and they don't exit before main() does, there will be problems. I haven't particularly tested this with threads yet - that's targeted for the later on. It can also affect the stack trace slightly. Requested Features? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I am still toying with the idea of allowing targeted tracking through the use of the suppression system - exclusively report on a specified malloc() call. show hanging pointers at a targeted call to free(). turn on more verbose output for a given memory block. Generate leak reports in some XML format to make machine parsing simple. If you use Omega and think any of these features would be useful or have requests of your own, please let me know. As ever, I would welcome your comments, bug reports and especially any news of success stories. Please share them with us on the list and copy me in so I don't miss them. thanks and happy hunting, Bryan "Brain Murders" Meredith -------------------------------------------------------------------------= Using Tomcat but need to do more? Need to support web services, = security? Get stuff done quickly with pre-integrated technology to make your job = easier Download IBM WebSphere Application Server v.1.0.1 based on Apache = Geronimo http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D= 121642 _______________________________________________ Valgrind-developers mailing list Val...@li... https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Tom H. <th...@cy...> - 2006-09-03 02:24:30
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2006-09-03 03:15:02 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/ccEL5KxB.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccEL5KxB.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccEL5KxB.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccEL5KxB.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccEL5KxB.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccEL5KxB.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccEL5KxB.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccEL5KxB.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.16333/valgrind/none/tests/x86' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/tmp/valgrind.16333/valgrind/none/tests/x86' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/tmp/valgrind.16333/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/valgrind.16333/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.16333/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/cc2O1xkY.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/cc2O1xkY.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/cc2O1xkY.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/cc2O1xkY.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/cc2O1xkY.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/cc2O1xkY.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/cc2O1xkY.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/cc2O1xkY.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.16333/valgrind/none/tests/x86' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/tmp/valgrind.16333/valgrind/none/tests/x86' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/tmp/valgrind.16333/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/valgrind.16333/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.16333/valgrind' make: *** [check] Error 2 ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Sun Sep 3 03:19:43 2006 --- new.short Sun Sep 3 03:24:25 2006 *************** *** 7,16 **** Last 20 lines of verbose log follow echo ! /tmp/cc2O1xkY.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/cc2O1xkY.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/cc2O1xkY.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/cc2O1xkY.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/cc2O1xkY.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/cc2O1xkY.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/cc2O1xkY.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/cc2O1xkY.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/ccEL5KxB.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccEL5KxB.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccEL5KxB.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccEL5KxB.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccEL5KxB.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccEL5KxB.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccEL5KxB.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccEL5KxB.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 |
|
From: Tom H. <th...@cy...> - 2006-09-03 02:19:34
|
Nightly build on lloyd ( x86_64, Fedora Core 3 ) started at 2006-09-03 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) |