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: Julian S. <js...@ac...> - 2003-11-03 14:58:50
|
CVS commit by jseward:
Merge in .cfi support from head:
configure.in 1.96 (partial) and 1.98
coregrind/vg_startup.S 1.17 and 1.18
M +17 -0 configure.in 1.93.2.3
M +17 -0 coregrind/vg_startup.S 1.16.2.1
--- valgrind/configure.in #1.93.2.2:1.93.2.3
@@ -282,4 +282,21 @@
+# check if the GNU as supports CFI directives
+AC_MSG_CHECKING([if gas accepts .cfi])
+AC_TRY_LINK(, [
+
+__asm__ __volatile__ (".cfi_startproc\n"
+ ".cfi_adjust_cfa_offset 0x0\n"
+ ".cfi_endproc\n");
+],
+[
+ AC_DEFINE_UNQUOTED([HAVE_GAS_CFI], 1, [Define if your GNU as supports .cfi])
+ AC_MSG_RESULT(yes)
+],
+ AC_MSG_RESULT(no)
+)
+
+
+
AC_MSG_CHECKING([if this is an NPTL-based system])
safe_LIBS="$LIBS"
--- valgrind/coregrind/vg_startup.S #1.16:1.16.2.1
@@ -31,4 +31,5 @@
#include "vg_constants.h"
+#include "../config.h"
@@ -229,6 +230,10 @@
.text
+.type VG_(swizzle_esp_then_start_GDB),@function
.global VG_(swizzle_esp_then_start_GDB)
VG_(swizzle_esp_then_start_GDB):
+#ifdef HAVE_GAS_CFI
+ .cfi_startproc
+#endif
pushal
@@ -257,6 +262,12 @@
# push %EBP. This is a faked %ebp-chain pointer.
pushl %eax
+#ifdef HAVE_GAS_CFI
+ .cfi_adjust_cfa_offset 0x4
+#endif
movl %esp, %ebp
+#ifdef HAVE_GAS_CFI
+ .cfi_def_cfa_register ebp
+#endif
call VG_(start_GDB_whilst_on_client_stack)
@@ -265,7 +276,13 @@
movl vg_ebp_saved_over_GDB_start, %ebp
movl vg_esp_saved_over_GDB_start, %esp
+#ifdef HAVE_GAS_CFI
+ .cfi_adjust_cfa_offset -0x4
+#endif
popal
ret
+#ifdef HAVE_GAS_CFI
+ .cfi_endproc
+#endif
# gcc puts this construction at the end of every function. I think it
|
|
From: Julian S. <js...@ac...> - 2003-11-03 14:45:58
|
CVS commit by jseward:
Merge rev 1.107:
Move var declarations to start of block, for older versions of gcc.
M +2 -2 vg_to_ucode.c 1.87.2.10
--- valgrind/coregrind/vg_to_ucode.c #1.87.2.9:1.87.2.10
@@ -3580,6 +3580,6 @@ static
void dis_push_segreg ( UCodeBlock* cb, UInt sreg, Int sz )
{
- vg_assert(sz == 4);
Int t1 = newTemp(cb), t2 = newTemp(cb);
+ vg_assert(sz == 4);
uInstr2(cb, GETSEG, 2, ArchRegS, sreg, TempReg, t1);
uInstr2(cb, GET, 4, ArchReg, R_ESP, TempReg, t2);
@@ -3595,6 +3595,6 @@ static
void dis_pop_segreg ( UCodeBlock* cb, UInt sreg, Int sz )
{
- vg_assert(sz == 4);
Int t1 = newTemp(cb), t2 = newTemp(cb);
+ vg_assert(sz == 4);
uInstr2(cb, GET, 4, ArchReg, R_ESP, TempReg, t2);
uInstr2(cb, LOAD, 2, TempReg, t2, TempReg, t1);
|
|
From: Julian S. <js...@ac...> - 2003-11-03 14:45:01
|
CVS commit by jseward:
Merge revs
mac_replace_strmem.c 1.5
tests/overlap.c 1.3
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.
M +6 -4 mac_replace_strmem.c 1.3.2.1
M +9 -0 tests/overlap.c 1.2.2.1
--- valgrind/memcheck/mac_replace_strmem.c #1.3:1.3.2.1
@@ -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.2.2.1
@@ -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: Julian S. <js...@ac...> - 2003-11-03 14:44:17
|
CVS commit by jseward:
Merge rev 1.106:
Implemented PUSH/POP %{FS,GS}, and PUSH %CS (Nb: there is no POP %CS). Based
on patches from Adam Gundy and Tom Hughes.
M +51 -44 vg_to_ucode.c 1.87.2.9
|
|
From: Julian S. <js...@ac...> - 2003-11-03 14:43:36
|
CVS commit by jseward: Merge rev 1.17: Updated FAQ #8, to reflect the fact that we now support a lot of SSE/SSE2 instructions. M +9 -13 FAQ.txt 1.7.2.4 --- valgrind/FAQ.txt #1.7.2.3:1.7.2.4 @@ -153,19 +153,15 @@ ----------------------------------------------------------------- -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 program without it by fiddling with the + -march=... flag(s) for gcc. In particular, get rid of + -march=pentium4 or -march=athlon if you can. Either way, let us + know and we'll try to fix it. ----------------------------------------------------------------- |
|
From: Julian S. <js...@ac...> - 2003-11-03 14:43:00
|
CVS commit by jseward:
Merge rev 1.52:
Add missing printf and pre_mem_read to rt_sigtimedwait(), thanks to Thomas
Lussnig <lu...@sm...>.
M +7 -2 vg_syscalls.c 1.40.2.5
--- valgrind/coregrind/vg_syscalls.c #1.40.2.4:1.40.2.5
@@ -1241,4 +1241,9 @@ void VG_(perform_assumed_nonblocking_sys
/* int sigtimedwait(const sigset_t *set, siginfo_t *info,
const struct timespec timeout); */
+ MAYBE_PRINTF("sigtimedwait ( %p, %p, timeout )\n", arg1, arg2);
+ if (arg1 != (UInt)NULL)
+ SYSCALL_TRACK( pre_mem_read, tid,
+ "sigtimedwait(set)", arg1,
+ sizeof(vki_ksigset_t));
if (arg2 != (UInt)NULL)
SYSCALL_TRACK( pre_mem_write, tid, "sigtimedwait(info)", arg2,
|
|
From: John L. <le...@mo...> - 2003-11-03 14:26:23
|
On Mon, Nov 03, 2003 at 11:14:58AM +0000, Nicholas Nethercote wrote: > I don't understand gcc's C99 support; it lets me do some things (such as > declarations not at the start of a block) without any command line args, > but other things, eg. "for (int i = 0; ...)" requires -std=c99. Why is > this? -std=xx means "accept code meeting that standard". "-pedantic[-errors]" is what changes whether non-standard code is accepted or not. > And is there a command-line option I can give to prevent me from > accidentally using non-block-starting declarations? -Wdeclaration-after-statement (in gcc 3.4) regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over. |
|
From: Nicholas N. <nj...@ca...> - 2003-11-03 12:10:06
|
CVS commit by nethercote:
Move var declarations to start of block, for older versions of gcc.
MERGE TO STABLE
M +2 -2 vg_to_ucode.c 1.107
--- valgrind/coregrind/vg_to_ucode.c #1.106:1.107
@@ -3597,6 +3597,6 @@ static
void dis_push_segreg ( UCodeBlock* cb, UInt sreg, Int sz )
{
- vg_assert(sz == 4);
Int t1 = newTemp(cb), t2 = newTemp(cb);
+ vg_assert(sz == 4);
uInstr2(cb, GETSEG, 2, ArchRegS, sreg, TempReg, t1);
uInstr2(cb, GET, 4, ArchReg, R_ESP, TempReg, t2);
@@ -3612,6 +3612,6 @@ static
void dis_pop_segreg ( UCodeBlock* cb, UInt sreg, Int sz )
{
- vg_assert(sz == 4);
Int t1 = newTemp(cb), t2 = newTemp(cb);
+ vg_assert(sz == 4);
uInstr2(cb, GET, 4, ArchReg, R_ESP, TempReg, t2);
uInstr2(cb, LOAD, 2, TempReg, t2, TempReg, t1);
|
|
From: Nicholas N. <nj...@ca...> - 2003-11-03 11:14:59
|
On Mon, 3 Nov 2003, Tom Hughes wrote: > A change made yesterday introduced a variable declaration that isn't > at the start of a block which stops the code compiling on older > versions of gcc that don't have C99 support. The attached patch > fixes this. Committed, thanks. I don't understand gcc's C99 support; it lets me do some things (such as declarations not at the start of a block) without any command line args, but other things, eg. "for (int i = 0; ...)" requires -std=c99. Why is this? And is there a command-line option I can give to prevent me from accidentally using non-block-starting declarations? Thanks. N |
|
From: Tom H. <th...@cy...> - 2003-11-03 09:53:30
|
A change made yesterday introduced a variable declaration that isn't at the start of a block which stops the code compiling on older versions of gcc that don't have C99 support. The attached patch fixes this. Tom -- Tom Hughes (th...@cy...) Software Engineer, Cyberscience Corporation http://www.cyberscience.com/ |
|
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] ----------------------------------------------------------------- |
|
From: Tom H. <th...@cy...> - 2003-11-01 17:26:23
|
In message <106...@sp...>
Robert Walsh <rj...@du...> wrote:
> > Is there some sort of problem with the new anonymous CVS server?
>
> Apparently it's dead. I'm using the
> :pserver:ano...@bl...:/home/kde mirror, which appears to
> be working. It also appears to be getting updates now.
That does look better, yes. I had been trying the kdecvs.student.utwente.nl
mirror which doesn't seem to be getting updates.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Robert W. <rj...@du...> - 2003-11-01 17:17:59
|
> Is there some sort of problem with the new anonymous CVS server? Apparently it's dead. I'm using the :pserver:ano...@bl...:/home/kde mirror, which appears to be working. It also appears to be getting updates now. Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Nicholas N. <nj...@ca...> - 2003-11-01 14:51:08
|
CVS commit by nethercote:
Make the startup static and suid checks follow symlinks.
Also a couple of minor formatting changes.
M +6 -6 valgrind.in 1.37
--- valgrind/coregrind/valgrind.in #1.36:1.37
@@ -118,11 +118,11 @@
which_prog=`which $1 2> /dev/null`
if [ z$which_prog = z ] ; then
- echo "'$1' not found in \$PATH, aborting."
- exit
+ echo "'$1' not found in \$PATH, aborting."
+ exit
fi
- # Ensure the program isn't statically linked.
if [ $# != 0 ] ; then
- case `file "$which_prog"` in
+ case `file -L "$which_prog"` in # must follow symlinks, hence -L
+ # Ensure the program isn't statically linked.
*"statically linked"*)
echo "\`$which_prog' is statically linked"
@@ -131,7 +131,7 @@
echo "to work with it. Read FAQ #5 for more information."
exit 1 ;;
- # ensure that there are no setuid or gid flags
+ # Ensure that there are no setuid or gid flags
*:\ set?id\ ELF*)
- echo "\`$which_prog' is suid/sgid."
+ echo "\`$which_prog' is suid/sgid."
echo "Valgrind can't handle these executables, as it"
echo "requires the LD_PRELOAD feature in order to work."
|
|
From: Nicholas N. <nj...@ca...> - 2003-11-01 14:04:07
|
CVS commit by nethercote:
Add missing printf and pre_mem_read to rt_sigtimedwait(), thanks to Thomas
Lussnig <lu...@sm...>.
MERGE TO STABLE
M +4 -0 vg_syscalls.c 1.52
--- valgrind/coregrind/vg_syscalls.c #1.51:1.52
@@ -3958,4 +3958,8 @@ PRE(rt_sigtimedwait)
/* int sigtimedwait(const sigset_t *set, siginfo_t *info,
const struct timespec timeout); */
+ MAYBE_PRINTF("sigtimedwait ( %p, %p, timeout )\n", arg1, arg2);
+ if (arg1 != (UInt)NULL)
+ SYSCALL_TRACK( pre_mem_read, tid, "sigtimedwait(set)", arg1,
+ sizeof(vki_ksigset_t));
if (arg2 != (UInt)NULL)
SYSCALL_TRACK( pre_mem_write, tid, "sigtimedwait(info)", arg2,
|
|
From: Nicholas N. <nj...@ca...> - 2003-11-01 11:40:09
|
On Sat, 1 Nov 2003, Tom Hughes wrote: > Is there some sort of problem with the new anonymous CVS server? > > Only I don't seem to have been able to connect to it at all since the > first night the source was moved, and the mirror that I tried doesn't > seem to be getting any updates. Hmm, it doesn't work for me either, doing this: cvs -d:pserver:ano...@an...:/home/kde co valgrind it just sat there not doing anything for a minute or two until I killed it. N |
|
From: Tom H. <th...@cy...> - 2003-11-01 08:01:52
|
Is there some sort of problem with the new anonymous CVS server? Only I don't seem to have been able to connect to it at all since the first night the source was moved, and the mirror that I tried doesn't seem to be getting any updates. Tom -- Tom Hughes (th...@cy...) Software Engineer, Cyberscience Corporation http://www.cyberscience.com/ |
|
From: Robert W. <rj...@du...> - 2003-11-01 03:09:02
|
> we check for possibly unsafe commits (unsafe in the sense of unsecure cod= e).=20 > printf is a bad function as it allows a lot of possbilities for buffer=20 > overflows, format string attacks and other manipulations when used not=20 > carefully.=20 Neat. Is the behavior documented anywhere? Are there escapes? Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Dirk M. <dm...@gm...> - 2003-11-01 02:02:16
|
On Saturday 01 November 2003 02:19, Robert Walsh wrote: > What on earth does POSSIBLY UNSAFE mean? we check for possibly unsafe commits (unsafe in the sense of unsecure code). printf is a bad function as it allows a lot of possbilities for buffer overflows, format string attacks and other manipulations when used not carefully. We also check for copyright statements and license declarations on newly added files, so that we can yell at the people that screw up. (we == KDE) Dirk |
|
From: Dirk M. <mu...@kd...> - 2003-11-01 01:59:54
|
CVS commit by mueller:
fix 'make dist'.
M +1 -0 Makefile.am 1.59
--- valgrind/coregrind/Makefile.am #1.58:1.59
@@ -89,4 +89,5 @@
vg_constants.h \
vg_symtab2.h \
+ vg_unistd.h \
vg_symtypes.h \
vg_unsafe.h
|
|
From: Robert W. <rj...@du...> - 2003-11-01 01:19:45
|
> A corecheck/tests/vgprintf.c 1.1 [POSSIBLY UNSAFE: printf] [no copyright] What on earth does POSSIBLY UNSAFE mean? |