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
(13) |
3
(3) |
4
(3) |
5
(4) |
|
6
(2) |
7
(4) |
8
(3) |
9
(2) |
10
|
11
|
12
(6) |
|
13
(6) |
14
(1) |
15
(2) |
16
(2) |
17
(2) |
18
|
19
|
|
20
|
21
|
22
(1) |
23
|
24
(2) |
25
(5) |
26
|
|
27
(1) |
28
(8) |
29
(3) |
30
|
|
|
|
|
From: Madhu M. K. <mm...@ya...> - 2003-04-13 19:43:43
|
Nicholas Nethercote wrote: >> I have a feeling that some of the cases are due to propagation >> (copying/passing undefined vals up and down through various subroutine >> calls), but there are a ton of places that it looks like the code >> assumes things start as zero. > >Assuming malloc'd memory is zeroed is an easy mistake to make, since many >malloc() implementations do zero even though this isn't required. (Not >sure about glibc, though.) Could the confusion be thanks to the fact that globals/statics are set to 0; sometime in the history of the development, these variables moved into the fuction? ... Just a thought. Cheerio, M p.s. Julian, can we please set the Reply-To to the list email id by default? If one is not careful, the possibility of spamming you or Nicholas is non trivial.... Madhu M Kurup /* Nemo Me Impune Lacessit */ mmk at yahoo-inc dt com |
|
From: Nathan N. <nn...@um...> - 2003-04-13 19:27:20
|
On Sun, 2003-04-13 at 04:37, Nicholas Nethercote wrote: > > I have a feeling that some of the cases are due to propagation > > (copying/passing undefined vals up and down through various subroutine > > calls), but there are a ton of places that it looks like the code > > assumes things start as zero. > > Assuming malloc'd memory is zeroed is an easy mistake to make, since many > malloc() implementations do zero even though this isn't required. (Not > sure about glibc, though.) Actually, I think most are for automatic vars in functions... but I'm not certain. Something I've seen that is a little odd is vg saying unitialized error and pointing at the last line of a function - on the brace. What data could it be referring to in that case? -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nn...@um... University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 |
|
From: Nathan N. <nn...@um...> - 2003-04-13 19:22:28
|
> You have probably already worked this out, but... the essential case
> corresponds to the 'post_mem_write' event. The non-essential cases
> correspond to the 'pre_mem_{read,write}' events. If any of the AFS system
> sub-calls 'allocate' or change the permissions of memory, eg. like mmap()
> or brk() or mprotect() do, then a new event (corresponding to eg.
> new_mem_mmap()) might be needed. Tell me if so, I can help you work out
> the details.
Not as far as I know... they should almost all be done with data getting
passed into the call. I figure that most of the afs syscall issues can
be resolved by marking that the syscall wrote to the memory. That should
hopefully get all of the propagation issues fixed relative the system
calls. Of course, that leaves thousands of other places.
I must say that in the short time I've been fiddling with valgrind (a
day), I really really resent the fact that I didn't have this tool a few
years ago. :) Makes dmalloc and efence look like toys. (Excellent tools,
but valgrind kicks butt.)
-- Nathan
------------------------------------------------------------
Nathan Neulinger EMail: nn...@um...
University of Missouri - Rolla Phone: (573) 341-4841
Computing Services Fax: (573) 341-4216
|
|
From: Eyal L. <ey...@ey...> - 2003-04-13 14:15:56
|
I submitted the patch during 1.9.4 but I do not see it in 1.9.5. I need it and have to apply it again. So here it is again for 1.9.5, let me know if there is any problem with it or how I should I submit it properly. This patch enables timestamping error reports to allow correlating them to other activity on the machine. It adds the option --time-stamp and a related --time-zone option to specify your time offset relative to UTC. -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> |
|
From: Nicholas N. <nj...@ca...> - 2003-04-13 09:37:37
|
On 12 Apr 2003, Nathan Neulinger wrote: > Thanks, found that in the docs and c-faq after reading closer. Looking > around and testing against the afs code, it is very clear that this code > is in need of some major grinding. A small number of the instances are > bogus, due to the afs syscall not being processed yet. But there are > many hundreds of other places where it is not so easily dismissed. > > I have a feeling that some of the cases are due to propagation > (copying/passing undefined vals up and down through various subroutine > calls), but there are a ton of places that it looks like the code > assumes things start as zero. Assuming malloc'd memory is zeroed is an easy mistake to make, since many malloc() implementations do zero even though this isn't required. (Not sure about glibc, though.) > Question related to adding the afs_syscall support (which so far seems > straightforward). I have a structure definition and about 30-40 AFSCALL_ > and AFSPIOCTL_ defines (instead of coding them in numerically). Where > would it be best to put these? It didn't look like vg_include.h was > appropriate. > > Right now, I just have them stuck in vg_syscalls.c somewhere. If the support is only needed within vg_syscalls.c, then that is probably the best place -- might as well keep the defitions local. N |
|
From: Nicholas N. <nj...@ca...> - 2003-04-13 09:32:50
|
On Sat, 12 Apr 2003, Julian Seward wrote:
> Well, there's a distinction to be made between _want_ and _need_.
> At the bare minimum, you _must_ say how the state of memory is
> altered after the syscall, otherwise memory checking won't work
> correctly. You need to tell V about changes in memory permissions
> after the call.
>
> Optionally -- and this is done with almost all syscalls -- you can
> add some stuff which checks addressibility & definedness of memory
> passed to the system call. This is nice to have -- it enables
> V to tell people to see when they are passing garbage to syscalls
> -- but it isn't per se essential.
You have probably already worked this out, but... the essential case
corresponds to the 'post_mem_write' event. The non-essential cases
correspond to the 'pre_mem_{read,write}' events. If any of the AFS system
sub-calls 'allocate' or change the permissions of memory, eg. like mmap()
or brk() or mprotect() do, then a new event (corresponding to eg.
new_mem_mmap()) might be needed. Tell me if so, I can help you work out
the details.
Julian's classification of essential vs. non-essential was based around
the Memcheck skin, but since Valgrind can be used for writing other
program supervision tools by writing new skins; the 'non-essential' events
really should be included, as they might be essential for some other skin.
N
|