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: Josef W. <Jos...@gm...> - 2006-09-06 23:39:02
|
On Friday 01 September 2006 04:45, Julian Seward wrote: > > Should I push this (and/or r6044) into 3.2.1 ? [Just back from few days on holiday] Yes, probably good to have (r6044, too). I would feel more comfortable if a had a regression test for this annotation script; I have further changes in the queue for this script to get a useful "posttest" for callgrind at all. Josef |
|
From: Bryan M. <om...@br...> - 2006-09-06 21:19:13
|
Just found an interesting bug in the new function return tracking when using C++. Don't think that C will be affected as you can't do anything like the stuff you can do inside a class constructor. Any C++ users out there getting an error like this before your program actually even gets into main() ?: ==4018== Process terminating with default action of signal 11 (SIGSEGV) ==4018== Access not within mapped region at address 0xFFFFFFFFFFFFFFF8 If so, I'm on it and hope to have a proper solution in the next day or two (I'm ill at the moment so things have slowed down a bit). I know what it is but I will be chatting with the guys on the developer list to get a proper solution together that will always work. Sorry for the inconvenience, Bryan "Brain Murders" Meredith Bryan Meredith wrote: > 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: > ================== > 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: > ============= > 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: > ============= > 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? > =================== > 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=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Tony R. <ton...@bu...> - 2006-09-06 11:59:12
|
Le mardi 05 septembre 2006 =E0 18:13 +1000, Nicholas Nethercote a =E9crit : > On Tue, 5 Sep 2006, Bart Van Assche wrote: >=20 > > - Does the PTT tool report false positives ? >=20 > I got the impression from the email and the website it was a visualisatio= n=20 > tool rather than an error-detection tool, but I could be wrong. There is a visualisation option: a trace report file can be built and then used with the Paj=E9 tool. Paj=E9 is aimed at visualizing parallelized applications. See: http://forge.objectweb.org/projects/paje/ Paj=E9 is a great tool. He is designed to handle large trace file. But, when one has recorded trace events during hours, analyzing the whole trace seems not possible. So, the PTT Paj=E9 extension worked in June 2005, but we have not updated it in June 2006. So features may have disappeared. PTT is not only aimed at finding problems in small multi-threaded applications. It is designed to help understanding a problem that happens rarely or only after hours in a large application: it is possible to stop/start dynamically the collect of events and to extract traces that appeared between 2 dates. Regards, Tony |
|
From: Tony R. <ton...@bu...> - 2006-09-06 08:11:10
|
Le mardi 05 septembre 2006 =E0 06:56 +0200, Bart Van Assche a =E9crit : > Hello Tony, >=20 > Three questions: > - Is the paper about PTT available online ? Yes: http://www.linuxsymposium.org/2005/linuxsymposium_procv2.pdf Page 111 The PTT web-site provides 2006/June-updated explanations. > - Does the PTT tool report false positives ? PTT does not analyse where problems can be or if the program does obey the POSIX Thread rules. PTT simply traces the use of POSIX NPTL objects (Threads, Mutexes, ...) plus very important stages inside NPTL. A new feature also is to provide information about contention of threads. Analysis must be done AFTER traces have been recorded. So, one could build a tool aimed at analyzing the traces and checking if/when something goes wrong. Like 2 threads accessing an unprotected variable at same time, or more subtile programming mistakes. Based on the trace information, someone also could build a tool aimed at understanding how the application can be speed up, by understanding where are the bottlenecks (many threads waiting for one thread, as an example). > - You wrote about an impact on behavior. Can you explain this > further ? Yes. If you run a multi-threaded application on different environments: - different POSIX thread libraries - processors with different speeds - different Operating Systems - machines with different number of processors things will be executed in different ways. So bugs may stay hidden on an environment and suddenly appear when you change a very simple element of the environment. The same with a multi-threading debugging tool: the more the tool modifies the way the application runs its threads, the more you will be able to find new bugs, but the less you'll be able to catch the one appearing at customer's site, without the debugging tool at work. In fact, you cannot debug a multi-threaded application in many cases, since it makes the problem disappear ... PTT was designed in order to have the lowest possible impact to the performance, in order to modify as less as possible the order of scheduling of threads. No calls to routines or kernel are done. So that the bug can be traced and not got round, hidden. This has been tested with Java benchmark (Volano) and a HPC program (GLucas) on different architectures (ia32, x86_64, ppc, ia64). We know that scalability is not perfect with many CPUs (8, 16, ...). But the impact of PTT is less that 2 or 3 % on very pthread-consuming applications. Also, PTT can be used to understand if the problem is in the application or in NPTL, since it can trace 2 levels: use of NPTL, internal operations inside NPTL. Tony |
|
From: Tony R. <ton...@bu...> - 2006-09-06 07:50:50
|
Le mardi 05 septembre 2006 =E0 07:19 +1000, Nicholas Nethercote a =E9crit : > On Mon, 4 Sep 2006, Tony Reix wrote: > > 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. >=20 > That was true then, but Valgrind now doesn't replace the native thread=20 > library. Oh. So I have to refresh my knowledge about Helgrind and check that my claims are still correct. > It looks like an interesting tools, but I don't see why it should be part= of=20 > the Valgrind distribution. If it was built with Valgrind, maybe, but it=20 > seems to be unrelated apart from involving debugging. The 2 basic ideas of my email are 1) that NPTL does not provide the tools required by Distros in order to guarantee a good support of NPTL and multi-threading for Linux customers, and 2) that understanding where is the problem may be a deadful pain. At the very beginning of PTT, I was in contact with IBM JVM guys trying to understand the cause of a very annoying problem. These guys spent days and weeks to locate and understand the cause. Not all users of NPTL have this level of knowledge of Linux and NPTL. So, such a tool is very useful. Why add PTT to Valgrind ? Because it would be a good place to maintain it and to make it evolve, because many programmers/maintainers of multi-threading applications are surely looking at Helgrind when they encounter a problem. PTT is aimed not only to help programmers debug their own program, but also to help maintainers of complex multi-threading applications. Part of what is sometimes called RAS (Reliability, Availability, Serviceability). Tony |
|
From: Tom H. <th...@cy...> - 2006-09-06 03:48:09
|
Nightly build on dellow ( x86_64, Fedora Core 5 ) started at 2006-09-06 03:10: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 == 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. <to...@co...> - 2006-09-06 02:45:39
|
Nightly build on dunsmere ( athlon, Fedora Core 5 ) started at 2006-09-06 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-06 02:24:33
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2006-09-06 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/ccC3MQuZ.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccC3MQuZ.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccC3MQuZ.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccC3MQuZ.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccC3MQuZ.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccC3MQuZ.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccC3MQuZ.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccC3MQuZ.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.6834/valgrind/none/tests/x86' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/tmp/valgrind.6834/valgrind/none/tests/x86' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/tmp/valgrind.6834/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/valgrind.6834/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.6834/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/cciNBQ1d.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/cciNBQ1d.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/cciNBQ1d.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/cciNBQ1d.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/cciNBQ1d.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/cciNBQ1d.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/cciNBQ1d.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/cciNBQ1d.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.6834/valgrind/none/tests/x86' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/tmp/valgrind.6834/valgrind/none/tests/x86' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/tmp/valgrind.6834/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/valgrind.6834/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.6834/valgrind' make: *** [check] Error 2 ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Wed Sep 6 03:19:51 2006 --- new.short Wed Sep 6 03:24:29 2006 *************** *** 7,16 **** Last 20 lines of verbose log follow echo ! /tmp/cciNBQ1d.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/cciNBQ1d.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/cciNBQ1d.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/cciNBQ1d.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/cciNBQ1d.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/cciNBQ1d.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/cciNBQ1d.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/cciNBQ1d.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/ccC3MQuZ.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccC3MQuZ.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccC3MQuZ.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccC3MQuZ.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccC3MQuZ.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccC3MQuZ.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccC3MQuZ.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccC3MQuZ.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 |
|
From: Tom H. <th...@cy...> - 2006-09-06 02:19:43
|
Nightly build on lloyd ( x86_64, Fedora Core 3 ) started at 2006-09-06 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) |
|
From: Tom H. <th...@cy...> - 2006-09-06 02:14:15
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2006-09-06 03:00: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 == 268 tests, 6 stderr failures, 1 stdout failure, 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) |