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
(5) |
3
(11) |
4
(13) |
5
(1) |
6
(15) |
7
(1) |
8
(1) |
|
9
(2) |
10
(4) |
11
(15) |
12
(2) |
13
(12) |
14
(2) |
15
(3) |
|
16
(1) |
17
(16) |
18
(1) |
19
(32) |
20
(19) |
21
(3) |
22
|
|
23
|
24
(4) |
25
|
26
(1) |
27
(19) |
28
(4) |
29
(2) |
|
30
(3) |
|
|
|
|
|
|
|
From: Nicholas N. <nj...@ca...> - 2003-11-02 21:22:31
|
CVS commit by nethercote: Apply patch from Steve Grubb: It turns out that select is an open ended function that can take thousands of fds to select on if you are careful. fd_set as defined allocates 128 bytes of space, but you can allocate it dynamically. The bug goes like this...the programmer looks at maxfd and determines how many bytes it takes to allocate for the fd_set. Suppose 5 was the maximum fd. Going through the howmany macro yields 4 bytes. The sizeof fd_set is 128 bytes. If you do a rdfds_copy = *rfds, then valgrind overruns the rfds variable causing invalid reads. You can see real live code that does this around line 1260 of sshd.c from openssh. I discussed this problem with Damien Miller of the OpenSSH project since it was their code I was auditing. I then read the source to the linux kernel to make sure that it has no dependencies on the size of the structure passed in as the fd sets. It is very careful to look at n and then limit itself to the bytes indicated by n of the select call. The attached patch fixes this problem. I tested the Openssh daemon against this and the bug at select is now resolved. I did not look to see if poll is wrapped by valgrind. But it should be scalable too. (Nb: I haven't touched poll(), I don't understand it well enough to know if it needs fixing, let alone how to do so.) M +62 -20 vg_intercept.c 1.18.2.1 |
|
From: Nicholas N. <nj...@ca...> - 2003-11-02 17:45:39
|
CVS commit by nethercote:
Fixed bug in overlap check in strncpy() -- it was assuming the src was 'n'
bytes longs, when it could be shorter, which could cause false positives.
Added an example of this to the regtest.
MERGE TO STABLE
M +6 -4 mac_replace_strmem.c 1.5
M +9 -0 tests/overlap.c 1.3
--- valgrind/memcheck/mac_replace_strmem.c #1.4:1.5
@@ -187,11 +187,13 @@ char* strcpy ( char* dst, const char* sr
char* strncpy ( char* dst, const char* src, int n )
{
+ const Char* src_orig = src;
Char* dst_orig = dst;
Int m = 0;
- if (is_overlap(dst, src, n, n))
- complain3("strncpy", dst, src, n);
-
while (m < n && *src) { m++; *dst++ = *src++; }
+ /* Check for overlap after copying; all n bytes of dst are relevant,
+ but only m+1 bytes of src if terminator was found */
+ if (is_overlap(dst_orig, src_orig, n, (m < n) ? m+1 : n))
+ complain3("strncpy", dst, src, n);
while (m++ < n) *dst++ = 0; /* must pad remainder with nulls */
--- valgrind/memcheck/tests/overlap.c #1.2:1.3
@@ -113,4 +113,13 @@ int main(void)
strncat(a, a+20, 21);
+ /* This is ok, but once gave a warning when strncpy() was wrong,
+ and used 'n' for the length, even when the src was shorter than 'n' */
+ {
+ char dest[64];
+ char src [16];
+ strcpy( src, "short" );
+ strncpy( dest, src, 20 );
+ }
+
return 0;
}
|
|
From: Nicholas N. <nj...@ca...> - 2003-11-02 17:00:54
|
CVS commit by nethercote:
Implemented PUSH/POP %{FS,GS}, and PUSH %CS (Nb: there is no POP %CS). Based
on patches from Adam Gundy and Tom Hughes.
MERGE TO STABLE
M +51 -44 vg_to_ucode.c 1.106
|
|
From: Nicholas N. <nj...@ca...> - 2003-11-02 16:32:36
|
CVS commit by nethercote: Updated FAQ #8, to reflect the fact that we now support a lot of SSE/SSE2 instructions. MERGE TO STABLE M +7 -13 FAQ.txt 1.17 --- valgrind/FAQ.txt #1.16:1.17 @@ -137,19 +137,13 @@ ----------------------------------------------------------------- -Q8. My program dies (exactly) like this: +Q8. My program dies, printing a message like this along the way: - REPE then 0xF - valgrind: the `impossible' happened: - Unhandled REPE case + disInstr: unhandled instruction bytes: 0x66 0xF 0x2E 0x5 -A8. Yeah ... that I believe is a SSE or SSE2 instruction. Are you - building your app with -march=pentium4 or -march=athlon or - something like that? If you can somehow dissuade gcc from - producing SSE/SSE2 instructions, you may be able to avoid this. - Some folks have reported that removing the flag -march=... - works around this. - - I'd be interested to hear if you can get rid of it by changing - your application build flags. +A8. Valgrind doesn't support the full x86 instruction set, although + it now supports many SSE and SSE2 instructions. If you know + the failing instruction is an SSE/SSE2 instruction, you might + be able to recompile your progrma without it by using the flag + -march to gcc. Either way, let us know and we'll try to fix it. ----------------------------------------------------------------- |
|
From: Nicholas N. <nj...@ca...> - 2003-11-02 16:28:11
|
CVS commit by nethercote: Deleted FAQ #2, as it is no longer relevant for the head, thanks to Jeremy's syscalls changes. M +1 -17 FAQ.txt 1.16 --- valgrind/FAQ.txt #1.15:1.16 @@ -41,21 +41,5 @@ ----------------------------------------------------------------- -Q2. My program dies complaining that syscall 197 is unimplemented. - -A2. 197, which is fstat64, is supported by valgrind. The problem is - that the /usr/include/asm/unistd.h on the machine on which your - valgrind was built, doesn't match your kernel -- or, to be more - specific, glibc is asking your kernel to do a syscall which is - not listed in /usr/include/asm/unistd.h. - - The fix is simple. Somewhere near the top of - coregrind/vg_syscalls.c, add the following line: - - #define __NR_fstat64 197 - - Rebuild and try again. The above line should appear before any - uses of the __NR_fstat64 symbol in that file. If you look at the - place where __NR_fstat64 is used in vg_syscalls.c, it will be - obvious why this fix works. +Q2. [Question erased, as it is no longer relevant] ----------------------------------------------------------------- |