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
(13) |
3
(7) |
|
4
(9) |
5
(23) |
6
(19) |
7
(18) |
8
(2) |
9
(7) |
10
(21) |
|
11
(13) |
12
|
13
(8) |
14
(17) |
15
(19) |
16
(25) |
17
(43) |
|
18
(22) |
19
(12) |
20
(19) |
21
(12) |
22
(9) |
23
(12) |
24
(5) |
|
25
(16) |
26
(25) |
27
(24) |
28
(19) |
29
(26) |
30
(25) |
31
(6) |
|
From: Tom H. <th...@cy...> - 2004-07-19 23:17:29
|
CVS commit by thughes: Some systems seem to need linux/netlink.h for linux/fs.h to compile correctly, so we include it beforehand in case. M +1 -0 vg_unsafe.h 1.31 --- valgrind/coregrind/vg_unsafe.h #1.30:1.31 @@ -65,4 +65,5 @@ #include <linux/timex.h> /* for adjtimex */ #include <linux/hdreg.h> /* for hard drive ioctls */ +#include <linux/netlink.h>/* Some systems need this for linux/fs.h */ #include <linux/fs.h> /* for filing system ioctls */ #ifdef HAVE_LINUX_FB_H |
|
From: Tom H. <th...@cy...> - 2004-07-19 12:30:26
|
I've finally found out what is causing bug #82114 where some people get assertions in vg_async_signalhandler when a child dies or some other asynchronous signal arrives. The problem is that VG_(gettid) assumes that if the gettid() system call fails with ENOSYS then the getpid() system call will actually get the ID of the current thread rather than that of the process. It seems however that there are some kernels (a 2.4.7 one is where it came up here) that have a getpid() that returns a single value for all threads but which don't have a gettid() system call. As a result the assertions in vg_async_signalhandler that try and ensure it is only called in a proxy thread are firing because it appears to be being called in the main thread even though it isn't. Unfortunately there doesn't seem to be a way to ask the kernel for the thread ID on these systems, so I'm not sure what the best thing is to do about this. Tom -- Tom Hughes (th...@cy...) Software Engineer, Cyberscience Corporation http://www.cyberscience.com/ |
|
From: John V. <jp...@ho...> - 2004-07-19 09:30:22
|
Hi Nicholas, This isn't exactly what I'm after, but it certainly is a good step in the right direction. I'll let you know how I get on... and thanks again for your time. /John. >From: Nicholas Nethercote <nj...@ca...> >To: John Vincent <jp...@ho...> >CC: val...@li... >Subject: Re: [Valgrind-developers] valgrind and -fcheck-memory-usage >Date: Mon, 19 Jul 2004 10:14:08 +0100 (BST) > >On Mon, 19 Jul 2004, John Vincent wrote: > >>Thanks for replying to my email. I've just re-read the sections you >>suggested, and while they're related, they're not quite what I was after. >>As I see it, the "Client Request" stuff is all about my code calling some >>routines defined inside valgrind. Please correct me if I've misunderstood. > >Mostly, although the VALGRIND_NON_SIMD_CALL[0123] requests let you call an >arbitrary function from your code, and it gets run on the real CPU and >doesn't get instrumented by Valgrind. > >>While this is very useful, what I wanted was for valgrind to (optionally) >>call routines defined in my code - specifically, valgrind keeps some kind >>of internal database or model of the memory state, the V and A bits. I'd >>like hooks so that when valrgind updates or queries this model, changing >>the values of the V and A bits, it could also call routines I've defined, >>which would then update or query an application-specific model I've >>defined. The "-fcheck-memory-usage" flag in gcc allowed me to write >>routines in my code to maintain an application-specific model of memory >>access, and the compiler arranged to call my routines whenever a memory >>access (read or write) occured. > >There are no hooks in the existing tools for calling functions on loads and >stores. Would the functions you call want to consult the A and V bits? If >so, you'll have to modify Memcheck/Addrcheck for your needs. If you just >want to call an arbitrary function on loads and stores, my tool "Dullard" >is a good place to start, see www.cl.cam.ac.uk/~njn25/software.html. > >N _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger |
|
From: Nicholas N. <nj...@ca...> - 2004-07-19 09:14:13
|
On Mon, 19 Jul 2004, John Vincent wrote: > Thanks for replying to my email. I've just re-read the sections you > suggested, and while they're related, they're not quite what I was after. As > I see it, the "Client Request" stuff is all about my code calling some > routines defined inside valgrind. Please correct me if I've misunderstood. Mostly, although the VALGRIND_NON_SIMD_CALL[0123] requests let you call an arbitrary function from your code, and it gets run on the real CPU and doesn't get instrumented by Valgrind. > While this is very useful, what I wanted was for valgrind to (optionally) > call routines defined in my code - specifically, valgrind keeps some kind of > internal database or model of the memory state, the V and A bits. I'd like > hooks so that when valrgind updates or queries this model, changing the > values of the V and A bits, it could also call routines I've defined, which > would then update or query an application-specific model I've defined. The > "-fcheck-memory-usage" flag in gcc allowed me to write routines in my code to > maintain an application-specific model of memory access, and the compiler > arranged to call my routines whenever a memory access (read or write) > occured. There are no hooks in the existing tools for calling functions on loads and stores. Would the functions you call want to consult the A and V bits? If so, you'll have to modify Memcheck/Addrcheck for your needs. If you just want to call an arbitrary function on loads and stores, my tool "Dullard" is a good place to start, see www.cl.cam.ac.uk/~njn25/software.html. N |
|
From: Nicholas N. <nj...@ca...> - 2004-07-19 08:19:08
|
CVS commit by nethercote:
Add another C call helper.
M +8 -0 coregrind/vg_instrument.c 1.12
M +1 -0 include/vg_skin.h.base 1.27
--- valgrind/coregrind/vg_instrument.c #1.11:1.12
@@ -183,4 +183,12 @@ void VG_(ccall_RLL_0)(UCodeBlock* cb, Ad
}
+// f(lit, reg, reg)
+void VG_(ccall_LRR_0)(UCodeBlock* cb, Addr f, UInt lit1, UInt t2,
+ UInt t3, UInt regparms_n)
+{
+ UInt t1 = VG_(lit_to_newreg)(cb, lit1);
+ VG_(ccall_RRR_0)(cb, f, t1, t2, t3, regparms_n);
+}
+
// f(lit, lit, reg)
void VG_(ccall_LLR_0)(UCodeBlock* cb, Addr f, UInt lit1, UInt lit2,
--- valgrind/include/vg_skin.h.base #1.26:1.27
@@ -1189,4 +1189,5 @@
EV VG_(ccall_RRR_0) ( CB_F, UInt R1, UInt R2, UInt R3, RPn );
EV VG_(ccall_RLL_0) ( CB_F, UInt R1, UInt L2, UInt L3, RPn );
+EV VG_(ccall_LRR_0) ( CB_F, UInt L1, UInt R2, UInt R3, RPn );
EV VG_(ccall_LLR_0) ( CB_F, UInt L1, UInt L2, UInt R3, RPn );
EV VG_(ccall_LLL_0) ( CB_F, UInt L1, UInt L2, UInt L3, RPn );
|
|
From: John V. <jp...@ho...> - 2004-07-19 07:46:39
|
Hello Nicholas, Thanks for replying to my email. I've just re-read the sections you suggested, and while they're related, they're not quite what I was after. As I see it, the "Client Request" stuff is all about my code calling some routines defined inside valgrind. Please correct me if I've misunderstood. While this is very useful, what I wanted was for valgrind to (optionally) call routines defined in my code - specifically, valgrind keeps some kind of internal database or model of the memory state, the V and A bits. I'd like hooks so that when valrgind updates or queries this model, changing the values of the V and A bits, it could also call routines I've defined, which would then update or query an application-specific model I've defined. The "-fcheck-memory-usage" flag in gcc allowed me to write routines in my code to maintain an application-specific model of memory access, and the compiler arranged to call my routines whenever a memory access (read or write) occured. Thanks for your time, /John. >From: Nicholas Nethercote <nj...@ca...> >To: John Vincent <jp...@ho...> >CC: val...@li... >Subject: Re: [Valgrind-developers] valgrind and -fcheck-memory-usage >Date: Sat, 17 Jul 2004 09:47:21 +0100 (BST) > >On Tue, 13 Jul 2004, John Vincent wrote: > >>I'm new to valgrind (3 days use) but I've already found it to be very >>useful, so a big thanks. > >Glad you like it! > >>The "-fcheck-memory-usage" option that used to exist in gcc was also very >>useful to me, since I could write my own checking routines with >>application-specific knowledge about when memory should and should not be >>accessed. Since this is no longer available in gcc, I wonder if it might >>be possible to implement similar "hooks" via the valgrind core? > >Have you read sections 2.7 and 3.7 of the manual, about client requests? If >I understand correctly, this is exactly what you want. > >N _________________________________________________________________ Use MSN Messenger to send music and pics to your friends http://www.msn.co.uk/messenger |
|
From: <js...@ac...> - 2004-07-19 02:57:58
|
Nightly build on nemesis ( SuSE 9.1 ) started at 2004-07-19 03:50:00 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow memcheck/tests/overlap (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/pushfpopf (stderr) memcheck/tests/realloc1 (stderr) memcheck/tests/realloc2 (stderr) memcheck/tests/realloc3 (stderr) memcheck/tests/sigaltstack (stderr) memcheck/tests/signal2 (stderr) memcheck/tests/supp1 (stderr) memcheck/tests/supp2 (stderr) memcheck/tests/suppfree (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/toobig-allocs (stderr) memcheck/tests/trivialleak (stderr) memcheck/tests/tronical (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/writev (stderr) memcheck/tests/zeropage (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <to...@co...> - 2004-07-19 02:25:07
|
Nightly build on dunsmere ( Fedora Core 2 ) started at 2004-07-19 03:20:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 173 tests, 7 stderr failures, 1 stdout failure ================= corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_socketpair (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/writev (stderr) none/tests/exec-sigmask (stdout) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-07-19 02:19:18
|
Nightly build on audi ( Red Hat 9 ) started at 2004-07-19 03:15:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 173 tests, 7 stderr failures, 0 stdout failures ================= corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_socketpair (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-07-19 02:13:15
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2004-07-19 03:10:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow sem: valgrind ./sem semlimit: valgrind ./semlimit sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 173 tests, 4 stderr failures, 0 stdout failures ================= helgrind/tests/deadlock (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-07-19 02:08:09
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2004-07-19 03:05:01 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 173 tests, 6 stderr failures, 1 stdout failure ================= addrcheck/tests/toobig-allocs (stderr) memcheck/tests/badjump (stderr) memcheck/tests/brk (stderr) memcheck/tests/error_counts (stdout) memcheck/tests/new_nothrow (stderr) memcheck/tests/toobig-allocs (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-07-19 02:07:04
|
Nightly build on standard ( Red Hat 7.2 ) started at 2004-07-19 03:00:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow rcrl: valgrind ./rcrl readline1: valgrind ./readline1 resolv: valgrind ./resolv rlimit_nofile: valgrind ./rlimit_nofile seg_override: valgrind ./seg_override sem: valgrind ./sem semlimit: valgrind ./semlimit sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 173 tests, 0 stderr failures, 0 stdout failures ================= |