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
(11) |
2
(9) |
3
(11) |
4
(12) |
5
(11) |
|
6
(9) |
7
(13) |
8
(6) |
9
(7) |
10
(7) |
11
(11) |
12
(13) |
|
13
(7) |
14
(6) |
15
(7) |
16
(19) |
17
(20) |
18
(9) |
19
(9) |
|
20
(6) |
21
(7) |
22
(11) |
23
(16) |
24
(14) |
25
(24) |
26
(16) |
|
27
(20) |
28
(58) |
29
(7) |
30
(10) |
31
(15) |
|
|
|
From: Bart V. A. <bar...@gm...> - 2006-08-12 13:25:12
|
Patch:
> svn diff coregrind/m_stacktrace.c
Index: coregrind/m_stacktrace.c
===================================================================
--- coregrind/m_stacktrace.c (revision 5998)
+++ coregrind/m_stacktrace.c (working copy)
@@ -412,8 +412,7 @@
void VG_(get_and_pp_StackTrace) ( ThreadId tid, UInt n_ips )
{
Addr ips[n_ips];
- VG_(get_StackTrace)(tid, ips, n_ips);
- VG_(pp_StackTrace) ( ips, n_ips);
+ VG_(pp_StackTrace)(ips, VG_(get_StackTrace)(tid, ips, n_ips));
}
Sample output without the patch:
==6404== at 0x4043EFE: __lll_mutex_lock_wait (in /lib/libpthread-2.4.so)
==6404== by 0x401C6D4: pthread_mutex_lock (vg_preloaded.c:177)
==6404== by 0x8051A05: STC::CPthreadMutex::Lock() (
synchronization-impl-linux.cpp:52)
==6404== by 0x804D69B: STC::CPosixThreadImpl::PthreadEntry(void*) (
thread-impl-linux.cpp:198)
==6404== by 0x401CB65: vg_thread_wrapper (vg_preloaded.c:96)
==6404== by 0x403E34A: start_thread (in /lib/libpthread-2.4.so)
==6404== by 0x421665D: clone (in /lib/libc-2.4.so)
==6404== by 0x52378DDB: ???
==6404== by 0x280082A2: vgPlain_vmessage (m_libcprint.c:325)
==6404== by 0x2812A59E: (within
/home/bart/software/valgrind-svn/inst/lib/valgrind/x86-linux/drd)
==6404== by 0x52378E03: ???
==6404== by 0x3C: ???
==6404== by 0x3C: ???
==6404== by 0x3D453142: ???
==6404== by 0x1000: ???
Sampel output with the patch applied:
==7563== at 0x4043EFE: __lll_mutex_lock_wait (in /lib/libpthread-2.4.so)
==7563== by 0x401C6D4: pthread_mutex_lock (vg_preloaded.c:177)
==7563== by 0x8051A05: STC::CPthreadMutex::Lock() (
synchronization-impl-linux.cpp:52)
==7563== by 0x804D69B: STC::CPosixThreadImpl::PthreadEntry(void*) (
thread-impl-linux.cpp:198)
==7563== by 0x401CB65: vg_thread_wrapper (vg_preloaded.c:96)
==7563== by 0x403E34A: start_thread (in /lib/libpthread-2.4.so)
==7563== by 0x421665D: clone (in /lib/libc-2.4.so)
|
|
From: Nicholas N. <nj...@cs...> - 2006-08-12 13:02:10
|
On Sat, 12 Aug 2006, Bart Van Assche wrote: >> Nice. So what's the status of DRD? > > What already works: > - support algorithms and data structures for the DIOTA algorithm: vector > clocks, bitmaps for recording read and write accesses during execution, > segments, keeping track of thread and mutex state information. > - data-race detection for so-called fork-join parallelism (pthread_create() > / pthread_join()). > - support for pthread mutexes. > - works already for toy examples (two threads / less than hundred mutex lock > and unlock operations). > > What is still missing (in order of importance): > - keeping track of all dynamically allocated memory. > - better error reporting for stack and heap variables. > - pthread condition variable state tracking and proper support for pthread > condition variables. > - testing with more complex multithreaded test programs. > - 64-bit support / testing on PPC (current implementation is only tested on > x86 yet). > - unit tests. > - documentation. Sounds good. There has a been a small but steady flow of comments from people who want Helgrind back -- they liked it even though it gave a lot of false positives. So if you can get this working well I think it will be well received. Nick |
|
From: Nicholas N. <nj...@cs...> - 2006-08-12 13:01:11
|
On Sat, 12 Aug 2006, Bart Van Assche wrote: > I followed the instructions in README_DEVELOPERS. Self-hosting valgrind with > tool none works, but running valgrind under the tool memcheck results in a > segmentation fault. Is this normal ? Probably... nobody (AFAIK) has really run Valgrind under Memcheck in any meaningful way, so it doesn't surprise me that it doesn't work. Nick |
|
From: Bart V. A. <bar...@gm...> - 2006-08-12 12:01:40
|
On 8/12/06, Nicholas Nethercote <nj...@cs...> wrote: > > On Sat, 12 Aug 2006, Bart Van Assche wrote: > > > Yes, the algorithm used in DRD recognizes user-built synchronization > > constructs (as long as these are implemented via POSIX thread > > synchronization function calls). And it doesn't report false positives > -- > > another known problem of the Eraser algorithm. > > Nice. So what's the status of DRD? > What already works: - support algorithms and data structures for the DIOTA algorithm: vector clocks, bitmaps for recording read and write accesses during execution, segments, keeping track of thread and mutex state information. - data-race detection for so-called fork-join parallelism (pthread_create() / pthread_join()). - support for pthread mutexes. - works already for toy examples (two threads / less than hundred mutex lock and unlock operations). What is still missing (in order of importance): - keeping track of all dynamically allocated memory. - better error reporting for stack and heap variables. - pthread condition variable state tracking and proper support for pthread condition variables. - testing with more complex multithreaded test programs. - 64-bit support / testing on PPC (current implementation is only tested on x86 yet). - unit tests. - documentation. ... Currently I'm debugging the thread and mutex support in drd, that's why I was asking about self-hosting valgrind. |
|
From: Bart V. A. <bar...@gm...> - 2006-08-12 11:40:09
|
On 8/10/06, Nicholas Nethercote <nj...@cs...> wrote: > > On Thu, 10 Aug 2006, Bart Van Assche wrote: > > > Anyone any idea where I can find documentation on recursive invocation > of > > valgrind, if this is supported ? I started working again on my drd > > (data-race detection) tool, and would like to test it with memcheck. Is > this > > possible ? > > Partly. README_DEVELOPERS has details on how to do this (under > "Self-hosting"). > > Unfortunately using Memcheck on another tool won't give you useful > results, > because we haven't added the necessary client requests to tell Memcheck > about all the nasty things Valgrind does with memory. So you'll get lots > of > false positives. > > Cachegrind works, however; that's how we got some of the speedups in > 3.2.0. > I followed the instructions in README_DEVELOPERS. Self-hosting valgrind with tool none works, but running valgrind under the tool memcheck results in a segmentation fault. Is this normal ? $ valgrind-outer-svn/inst/bin/valgrind --sim-hints=enable-inner --trace-children=yes --tool=none valgrind-inner-svn/inst/bin/valgrind --tool=none /bin/date ==30263== Nulgrind, a binary JIT-compiler. ==30263== Copyright (C) 2002-2006, and GNU GPL'd, by Nicholas Nethercote. ==30263== Using LibVEX rev 1636, a library for dynamic binary translation. ==30263== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. ==30263== Using valgrind-3.3.0.SVN, a dynamic binary instrumentation framework. ==30263== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. ==30263== For more details, rerun with: -v ==30263== ==30263== Nulgrind, a binary JIT-compiler. ==30263== Copyright (C) 2002-2006, and GNU GPL'd, by Nicholas Nethercote. ==30263== Using LibVEX rev 1636, a library for dynamic binary translation. ==30263== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. ==30263== Using valgrind-3.3.0.SVN, a dynamic binary instrumentation framework. ==30263== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. ==30263== For more details, rerun with: -v ==30263== >==30263== Nulgrind, a binary JIT-compiler. >==30263== Copyright (C) 2002-2006, and GNU GPL'd, by Nicholas Nethercote. >==30263== Using LibVEX rev 1636, a library for dynamic binary translation. >==30263== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. >==30263== Using valgrind-3.3.0.SVN, a dynamic binary instrumentation framework. >==30263== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. >==30263== For more details, rerun with: -v >==30263== Sat Aug 12 13:34:50 CEST 2006 >==30263== ==30263== $ valgrind-outer-svn/inst/bin/valgrind --sim-hints=enable-inner --trace-children=yes --tool=memcheck valgrind-inner-svn/inst/bin/valgrind --tool=none /bin/date ==30271== Memcheck, a memory error detector. ==30271== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. ==30271== Using LibVEX rev 1636, a library for dynamic binary translation. ==30271== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. ==30271== Using valgrind-3.3.0.SVN, a dynamic binary instrumentation framework. ==30271== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. ==30271== For more details, rerun with: -v ==30271== ==30271== Memcheck, a memory error detector. ==30271== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. ==30271== Using LibVEX rev 1636, a library for dynamic binary translation. ==30271== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. ==30271== Using valgrind-3.3.0.SVN, a dynamic binary instrumentation framework. ==30271== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. ==30271== For more details, rerun with: -v ==30271== >==30271== Nulgrind, a binary JIT-compiler. >==30271== Copyright (C) 2002-2006, and GNU GPL'd, by Nicholas Nethercote. >==30271== Using LibVEX rev 1636, a library for dynamic binary translation. >==30271== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. >==30271== Using valgrind-3.3.0.SVN, a dynamic binary instrumentation framework. >==30271== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. >==30271== For more details, rerun with: -v >==30271== ==30271== Invalid read of size 4 ==30271== at 0x2804CC52: vgModuleLocal_is_elf_object_file (readelf.c:112) ==30271== Address 0x38000000 is on thread 1's stack ==30271== ==30271== Invalid read of size 4 ==30271== at 0x2804CC54: vgModuleLocal_is_elf_object_file (readelf.c:116) ==30271== Address 0x38000004 is on thread 1's stack ==30271== ==30271== Invalid read of size 2 ==30271== at 0x2804CC57: vgModuleLocal_is_elf_object_file (readelf.c:119) ==30271== Address 0x38000010 is on thread 1's stack ==30271== ==30271== Invalid read of size 2 ==30271== at 0x2804CC5F: vgModuleLocal_is_elf_object_file (readelf.c:120) ==30271== Address 0x38000012 is on thread 1's stack ==30271== ==30271== Invalid read of size 4 ==30271== at 0x2804CC63: vgModuleLocal_is_elf_object_file (readelf.c:121) ==30271== Address 0x38000014 is on thread 1's stack ==30271== ==30271== Invalid read of size 2 ==30271== at 0x2804CC69: vgModuleLocal_is_elf_object_file (readelf.c:122) ==30271== Address 0x38000032 is on thread 1's stack ==30271== ==30271== Invalid read of size 4 ==30271== at 0x2804CC74: vgModuleLocal_is_elf_object_file (readelf.c:123) ==30271== Address 0x38000020 is on thread 1's stack ==30271== ==30271== Invalid read of size 2 ==30271== at 0x2804CC7A: vgModuleLocal_is_elf_object_file (readelf.c:123) ==30271== Address 0x38000030 is on thread 1's stack ==30271== ==30271== Invalid read of size 4 ==30271== at 0x2804CC88: vgModuleLocal_is_elf_object_file (readelf.c:124) ==30271== Address 0x3800001C is on thread 1's stack ==30271== ==30271== Invalid read of size 2 ==30271== at 0x2804CC8E: vgModuleLocal_is_elf_object_file (readelf.c:124) ==30271== Address 0x3800002C is on thread 1's stack ==30271== Warning: ignored attempt to set SIGRT32 handler in sigaction(); ==30271== the SIGRT32 signal is used internally by Valgrind ==30271== Warning: client switching stacks? SP change: 0x286E22A8 --> 0x51D17FF0 ==30271== to suppress, use: --max-stackframe=694377800 or greater >--30271-- VG_USERREQ__CLIENT_CALL1: func=0x0 >--30271-- VG_USERREQ__CLIENT_CALL1: func=0x0 >--30271-- VG_USERREQ__CLIENT_CALL1: func=0x0 ==30271== ==30271== Invalid read of size 1 ==30271== at 0x51D456FA: ??? ==30271== Address 0x0 is not stack'd, malloc'd or (recently) free'd >==30271== >==30271== Process terminating with default action of signal 11 (SIGSEGV) >==30271== Access not within mapped region at address 0x0 >==30271== at 0x40241CB: strcmp (mc_replace_strmem.c:340) >==30271== by 0x406F4B1: _nl_explode_name (in /lib/libc-2.4.so) >==30271== by 0x4068BB5: _nl_find_locale (in /lib/libc-2.4.so) >==30271== by 0x40683B8: setlocale (in /lib/libc-2.4.so) >==30271== by 0x80496B6: (within /bin/date) >==30271== by 0x405E87B: (below main) (in /lib/libc-2.4.so) >==30271== ==30271== ==30271== Process terminating with default action of signal 11 (SIGSEGV) ==30271== General Protection Fault ==30271== at 0x4173AD2: _pthread_cleanup_push_defer (in /lib/libpthread- 2.4.so) ==30271== by 0xBE: ??? ==30271== by 0x3: ??? ==30271== by 0x62527707: ??? ==30271== ==30271== ERROR SUMMARY: 11 errors from 11 contexts (suppressed: 0 from 0) ==30271== malloc/free: in use at exit: 0 bytes in 0 blocks. ==30271== malloc/free: 0 allocs, 0 frees, 0 bytes allocated. ==30271== For counts of detected errors, rerun with: -v ==30271== All heap blocks were freed -- no leaks are possible. Segmentation fault |
|
From: Nicholas N. <nj...@cs...> - 2006-08-12 10:02:32
|
On Sat, 12 Aug 2006, Bart Van Assche wrote: > Yes, the algorithm used in DRD recognizes user-built synchronization > constructs (as long as these are implemented via POSIX thread > synchronization function calls). And it doesn't report false positives -- > another known problem of the Eraser algorithm. Nice. So what's the status of DRD? Nick |
|
From: Bart V. A. <bar...@gm...> - 2006-08-12 09:53:55
|
Yes, the algorithm used in DRD recognizes user-built synchronization constructs (as long as these are implemented via POSIX thread synchronization function calls). And it doesn't report false positives -- another known problem of the Eraser algorithm. On 8/12/06, Nicholas Nethercote <nj...@cs...> wrote: > > On Sat, 12 Aug 2006, Bart Van Assche wrote: > > > For who is interested in data-race detection, the conclusion of > Muhlenfeld's > > paper points out a fundamental limitation of Helgrind and other tools > based > > on the Eraser algorithm: these tools do not recognize user-built > > synchronization constructs. E.g. in many applications reader-writer > locks > > are implemented as a mutex + counter instead of calling the > > pthread_rwlock_...() functions. > > > >> From the conclusion: > > Further improvements could have a similar impact on the detection > > abilities of the data race checker, but require more effort. > > The weaknesses with regard to common multi-threading > > patterns should be addressed. Common concurrent patterns > > often rely on higher level constructs for synchronization that > > the lock-set algorithm is unaware of. > > Does the algorithm used by drd fix these problems? > |
|
From: Nicholas N. <nj...@cs...> - 2006-08-12 09:40:35
|
On Sat, 12 Aug 2006, Bart Van Assche wrote: > For who is interested in data-race detection, the conclusion of Muhlenfeld's > paper points out a fundamental limitation of Helgrind and other tools based > on the Eraser algorithm: these tools do not recognize user-built > synchronization constructs. E.g. in many applications reader-writer locks > are implemented as a mutex + counter instead of calling the > pthread_rwlock_...() functions. > >> From the conclusion: > Further improvements could have a similar impact on the detection > abilities of the data race checker, but require more effort. > The weaknesses with regard to common multi-threading > patterns should be addressed. Common concurrent patterns > often rely on higher level constructs for synchronization that > the lock-set algorithm is unaware of. Does the algorithm used by drd fix these problems? Nick |
|
From: Tom H. <th...@cy...> - 2006-08-12 07:53:42
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2006-08-12 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 == 262 tests, 5 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/tls (stdout) |
|
From: Bart V. A. <bar...@gm...> - 2006-08-12 06:58:15
|
For who is interested in data-race detection, the conclusion of Muhlenfeld's paper points out a fundamental limitation of Helgrind and other tools based on the Eraser algorithm: these tools do not recognize user-built synchronization constructs. E.g. in many applications reader-writer locks are implemented as a mutex + counter instead of calling the pthread_rwlock_...() functions. >From the conclusion: Further improvements could have a similar impact on the detection abilities of the data race checker, but require more effort. The weaknesses with regard to common multi-threading patterns should be addressed. Common concurrent patterns often rely on higher level constructs for synchronization that the lock-set algorithm is unaware of. On 8/12/06, sv...@va... <sv...@va...> wrote: > > Author: njn > Date: 2006-08-12 05:33:35 +0100 (Sat, 12 Aug 2006) > New Revision: 293 > > Log: > Added two papers by others about Valgrind. > > Added: > trunk/docs/muehlenfeld2006.pdf > trunk/docs/newsome2005.pdf > Modified: > trunk/docs/pubs.html ... + <li><p> > + <b><a href="/docs/muehlenfeld2006.pdf">Fault Detection in Multi-Threaded > C++ > + Server Applications.</a><br> > + Arndt Muehlenfeld and Franz Wotawa.<br> > + Informal Proceedings of the International Workshop on Multithreading in > + Hardware and Software (TV06), Seattle, Washington, USA, August > 2006.</b><br> > + This paper is about some improvements to Helgrind, the data-race > detector. > + </p></li> > |
|
From: <sv...@va...> - 2006-08-12 04:33:42
|
Author: njn
Date: 2006-08-12 05:33:35 +0100 (Sat, 12 Aug 2006)
New Revision: 293
Log:
Added two papers by others about Valgrind.
Added:
trunk/docs/muehlenfeld2006.pdf
trunk/docs/newsome2005.pdf
Modified:
trunk/docs/pubs.html
Added: trunk/docs/muehlenfeld2006.pdf
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
(Binary files differ)
Property changes on: trunk/docs/muehlenfeld2006.pdf
___________________________________________________________________
Name: svn:mime-type
+ application/octet-stream
Added: trunk/docs/newsome2005.pdf
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
(Binary files differ)
Property changes on: trunk/docs/newsome2005.pdf
___________________________________________________________________
Name: svn:mime-type
+ application/octet-stream
Modified: trunk/docs/pubs.html
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/docs/pubs.html 2006-08-03 12:22:07 UTC (rev 292)
+++ trunk/docs/pubs.html 2006-08-12 04:33:35 UTC (rev 293)
@@ -1,11 +1,14 @@
<h1>Valgrind Publications</h1>
=20
-<p>Here are some academic publications that have been written by Valgrin=
d
-developers. If you refer to Valgrind in a publication, please cite one =
or
+<p>Here are some academic publications that are about Valgrind or involv=
e
+Valgrind significantly.</p>
+
+<h2>Papers By Valgrind Developers</h2>
+
+<p>If you refer to Valgrind in a publication, please cite one or
more of the following papers, not just the Valgrind website.</p>
=20
<ul>
-
<li><p>
<b><a href=3D"/docs/memcheck2005.pdf">Using Valgrind to detect undefine=
d value
errors with bit-precision.</a><br>
@@ -37,7 +40,11 @@
Informal Proceedings of the Second Workshop on Semantics, Program
Analysis, and Computing Environments for Memory Management (SPACE 20=
04),
Venice, Italy, January 2004.</b><br>
- This paper describes Annelid, an experimental bounds checker.
+ This paper describes Annelid, an experimental bounds checker. Althoug=
h
+ the paper is upbeat about Annelid, it really didn't work that well.
+ Good bounds-checking relies too much on source-level information (such=
as
+ what values are pointers, and what things those pointers point to) tha=
t is
+ difficult to obtain when working at the binary level.
</p></li>
=20
<li><p>
@@ -53,11 +60,41 @@
Nicholas Nethercote and Alan Mycroft.<br>
Electronic Notes in Theoretical Computer Science 89 No. 2, 2003.</b><b=
r>
This paper describes Redux, and experimental dynamic dataflow tracing
- tool.
+ tool. Redux is fun and intriguing, although wildly unscaleable. The
+ paper suggests multiple uses for it, none of which are likely to be
+ practical. What it <emph>is</emph> genuinely good for is stimulating
+ ideas about the kinds of tools that Valgrind can be used to build; pe=
ople
+ see the graphs and say "oh, if you just changed X to Y, you could do Z=
"...
+ they usually end up describing something entirely different to Redux t=
hat
+ they wouldn't have thought of without seeing Redux's graphs. So reall=
y
+ it's best described as an ideas-for-Valgrind-tools stimulator!
</p></li>
=20
</ul>
=20
+<h2>Papers By Others</h2>
+<ul>
=20
+ <li><p>
+ <b><a href=3D"/docs/muehlenfeld2006.pdf">Fault Detection in Multi-Threa=
ded C++
+ Server Applications.</a><br>
+ Arndt Muehlenfeld and Franz Wotawa.<br>
+ Informal Proceedings of the International Workshop on Multithreading i=
n
+ Hardware and Software (TV06), Seattle, Washington, USA, August 2006.</=
b><br>
+ This paper is about some improvements to Helgrind, the data-race detec=
tor.
+ </p></li>
+
+ <li><p>
+ <b><a href=3D"/docs/newsome2005.pdf">Dynamic taint analysis for automat=
ic
+ detection, analysis, and signature generation of exploits on commodity
+ software.</a><br>
+ James Newsome and Dawn Song.<br>
+ Proceedings of the 12th Annual Network and Distributed System Security
+ Symposium (NDSS '05), February 2005.</b><br>
+ This paper is about a security tool built with Valgrind.
+ </p></li>
+
+</ul>
+
<p> </p>
<p> </p>
|
|
From: Tom H. <to...@co...> - 2006-08-12 02:45:33
|
Nightly build on dunsmere ( athlon, Fedora Core 5 ) started at 2006-08-12 03:30: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 == 237 tests, 4 stderr failures, 0 stdout failures, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) |
|
From: Tom H. <th...@cy...> - 2006-08-12 02:25:36
|
Nightly build on dellow ( x86_64, Fedora Core 5 ) started at 2006-08-12 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 == 260 tests, 3 stderr failures, 0 stdout failures, 0 posttest failures == memcheck/tests/mempool (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) |