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-19 09:59:30
|
On Wed, 19 Nov 2003, Dirk Mueller wrote: > CVS commit by mueller: > > implement statfs64, utimes and clock_gettime The HEAD now doesn't compile on my machine: vg_syscalls.c: In function `before_statfs64': vg_syscalls.c:4070: sizeof applied to an incomplete type vg_syscalls.c: In function `after_statfs64': vg_syscalls.c:4075: sizeof applied to an incomplete type Also, not printing the "discarding..." message will, I think, break some regression tests. These problems may also apply to the stable branch. Can you fix them? Thanks. And don't forget to run the regression tests before committing :) N |
|
From: Dirk M. <mu...@kd...> - 2003-11-19 08:57:21
|
CVS commit by mueller:
make use of statfs64 and make code blocks adjacent
M +6 -6 vg_syscalls.c 1.58
--- valgrind/coregrind/vg_syscalls.c #1.57:1.58
@@ -4057,4 +4057,9 @@ PRE(statfs)
}
+POST(statfs)
+{
+ VG_TRACK( post_mem_write, arg2, sizeof(struct statfs) );
+}
+
PRE(statfs64)
{
@@ -4063,10 +4068,5 @@ PRE(statfs64)
SYSCALL_TRACK( pre_mem_read_asciiz, tid, "statfs64(path)", arg1 );
SYSCALL_TRACK( pre_mem_write, tid, "statfs64(buf)",
- arg2, sizeof(struct statfs) );
-}
-
-POST(statfs)
-{
- VG_TRACK( post_mem_write, arg2, sizeof(struct statfs) );
+ arg2, sizeof(struct statfs64) );
}
|
|
From: Jeremy F. <je...@go...> - 2003-11-19 04:28:52
|
OK, I've had even more of a look into what's happening here. The quick
answer is that is can probably be done without too much nastiness,
though our libpthread will need to know some of glibc's secret
knowledge.
The key thing is that %gs points to a thing called tcbhead_t, which
contains pointers to the rest of the thread-specific data structures.
pthread_create doesn't really do much with this except init it;
___tls_get_addr does all the hard work of on-demand copying, which we
don't care about.
Aside from the shape of tcbhead_t (which is simple), libpthread doesn't
need to know much about how it works - it ends up calling _dl_* internal
functions to manipulate it, and to find out other info it needs to know
(like how big the static per-thread info is, which it needs to build
into the thread stack).
Our libpthread can call those same functions, and thereby do the same
thing.
For reference, they appear to be:
_dl_get_tls_static_info(size_t *size, size_t *alignment)
Get the size and alignment of the per-thread variable space we
need to stick on the stack under tcbhead_t.
_dl_allocate_tls_init(void *mem)
(Re)Initialize the TLS info at mem. mem points to the
tcbhead_t.
_dl_allocate_tls(void *mem)
Do the initial initialization of the TCB (ie, allocate the DTV).
_dl_deallocate_tls(void *mem, bool free_tcb)
Deallocate memory.
tcbhead_t is:
typedef struct
{
void *tcb; /* Pointer to the TCB. Not necessary the
thread descriptor used by libpthread. */
dtv_t *dtv;
void *self; /* Pointer to the thread descriptor. */
int multiple_threads;
uintptr_t sysinfo;
} tcbhead_t;
We don't care about dtv_t, since the dynamic linker will do all the work
to maintain it.
The other part is implementing the TLS "kernel" support, which is easy.
So in all, this only looks like a few day's work (maybe less).
J
|
|
From: Dirk M. <mu...@kd...> - 2003-11-19 00:58:29
|
CVS commit by mueller:
be more silent by default
M +4 -3 vg_symtab2.c 1.48.2.3
--- valgrind/coregrind/vg_symtab2.c #1.48.2.2:1.48.2.3
@@ -2300,4 +2300,5 @@ void VG_(unload_symbols) ( Addr start, U
return;
+ if (VG_(clo_verbosity) > 0)
VG_(message)(Vg_UserMsg,
"discard syms in %s due to munmap()",
|
|
From: Dirk M. <mu...@kd...> - 2003-11-19 00:57:44
|
CVS commit by mueller:
raise sanity check to pass coreutils testsuite
M +2 -2 vg_main.c 1.110.2.4
--- valgrind/coregrind/vg_main.c #1.110.2.3:1.110.2.4
@@ -860,7 +860,7 @@ static void process_cmd_line_options ( v
sp --;
if (*sp == 0) break;
- if (++ctr >= 1000)
+ if (++ctr >= 2000)
args_grok_error(
- "suspiciously many (1000) env[] entries; giving up");
+ "suspiciously many (2000) env[] entries; giving up");
}
|
|
From: Dirk M. <mu...@kd...> - 2003-11-19 00:57:16
|
CVS commit by mueller:
implement utimes, fstat64
M +23 -0 vg_syscalls.c 1.40.2.8
M +2 -1 vg_unsafe.h 1.14.2.4
--- valgrind/coregrind/vg_syscalls.c #1.40.2.7:1.40.2.8
@@ -3257,4 +3257,27 @@ void VG_(perform_assumed_nonblocking_sys
break;
+# if defined(__NR_statfs64)
+ case __NR_statfs64: /* syscall 268 */
+ /* int statfs64(const char *path, struct statfs64 *buf); */
+ MAYBE_PRINTF("statfs64 ( %s, %p )\n", arg1,arg2);
+ SYSCALL_TRACK( pre_mem_read_asciiz, tid, "statfs64(path)", arg1 );
+ KERNEL_DO_SYSCALL(tid,res);
+ if (!VG_(is_kerror)(res) && res == 0)
+ VG_TRACK( post_mem_write,arg2, sizeof(struct statfs64) );
+ break;
+# endif
+
+# if defined(__NR_utimes)
+ case __NR_utimes: /* syscall 271 */
+ /* int utimes(const char *filename, struct timeval *tvp); */
+ MAYBE_PRINTF("utimes ( %p, %p )\n", arg1,arg2);
+ SYSCALL_TRACK( pre_mem_read_asciiz, tid, "utimes(filename)", arg1 );
+ if (arg2 != (UInt)NULL)
+ SYSCALL_TRACK( pre_mem_read, tid, "utimes(tvp)", arg2,
+ sizeof(struct timeval) );
+ KERNEL_DO_SYSCALL(tid,res);
+ break;
+# endif
+
case __NR_symlink: /* syscall 83 */
/* int symlink(const char *oldpath, const char *newpath); */
--- valgrind/coregrind/vg_unsafe.h #1.14.2.3:1.14.2.4
@@ -84,5 +84,6 @@
#include <sys/types.h>
-#include <sys/statfs.h>
+#include <asm/statfs.h>
+#undef statfs
#include <sys/sysinfo.h>
|
|
From: Dirk M. <mu...@kd...> - 2003-11-19 00:56:23
|
CVS commit by mueller: updating .cvsignore M +4 -0 addrcheck/tests/.cvsignore 1.2 M +11 -0 corecheck/tests/.cvsignore 1.4 M +10 -0 helgrind/tests/.cvsignore 1.2 M +7 -0 memcheck/tests/.cvsignore 1.7 --- valgrind/addrcheck/tests/.cvsignore #1.1:1.2 @@ -1,2 +1,6 @@ Makefile.in Makefile +badrw.stderr.diff +badrw.stderr.out +fprw.stderr.diff +fprw.stderr.out --- valgrind/corecheck/tests/.cvsignore #1.3:1.4 @@ -16,2 +16,13 @@ *.stdout.out *.stderr.out +fdleak_cmsg +fdleak_creat +fdleak_dup +fdleak_dup2 +fdleak_fcntl +fdleak_ipv4 +fdleak_open +fdleak_pipe +fdleak_socketpair +pth_exit +vgprintf --- valgrind/helgrind/tests/.cvsignore #1.1:1.2 @@ -1,2 +1,12 @@ Makefile.in Makefile +allok +allok.stderr.diff +allok.stderr.out +deadlock +deadlock.stderr.out +deadlock.stdout.out +inherit +race +race2 +readshared --- valgrind/memcheck/tests/.cvsignore #1.6:1.7 @@ -49,2 +49,9 @@ *.stdout.out *.stderr.out +badrw +brk +metadata +new_nothrow +realloc3 +threadederrno +writev |
|
From: Dirk M. <mu...@kd...> - 2003-11-19 00:56:02
|
CVS commit by mueller:
only say something if there is something to say
M +1 -3 vg_regtest.in 1.16
--- valgrind/tests/vg_regtest.in #1.15:1.16
@@ -275,5 +275,5 @@
# ignore dirs into which we should not recurse
- if ($dir =~ /^(BitKeeper|CVS|SCCS|docs|doc)$/) { return; }
+ if ($dir =~ /^(BitKeeper|CVS|SCCS|docs|doc)$/) { return; }
chdir($dir) or die "Could not change into $dir\n";
@@ -289,6 +289,4 @@
if ($found_tests) {
print "-- Running tests in $full_dir $dashes\n";
- } else {
- print "-- Found no tests in $full_dir $dashes\n";
}
foreach my $f (@fs) {
|
|
From: Dirk M. <mu...@kd...> - 2003-11-19 00:47:30
|
CVS commit by mueller:
be less verbose by default
M +4 -3 vg_symtab2.c 1.58
--- valgrind/coregrind/vg_symtab2.c #1.57:1.58
@@ -1184,4 +1184,5 @@ void VG_(unload_symbols) ( Addr start, U
}
+ if (VG_(clo_verbosity) > 1)
VG_(message)(Vg_UserMsg,
"discard syms in %s due to munmap()",
|
|
From: Dirk M. <mu...@kd...> - 2003-11-19 00:46:26
|
CVS commit by mueller:
raise sanity limit to pass coreutils testsuite
MERGE TO STABLE
M +2 -2 vg_main.c 1.123
--- valgrind/coregrind/vg_main.c #1.122:1.123
@@ -904,7 +904,7 @@ static void process_cmd_line_options ( v
sp --;
if (*sp == 0) break;
- if (++ctr >= 1000)
+ if (++ctr >= 2000)
args_grok_error(
- "suspiciously many (1000) env[] entries; giving up");
+ "suspiciously many (2000) env[] entries; giving up");
}
|
|
From: Dirk M. <mu...@kd...> - 2003-11-19 00:46:22
|
CVS commit by mueller:
implement statfs64, utimes and clock_gettime
M +42 -1 vg_syscalls.c 1.57
M +2 -1 vg_unsafe.h 1.20
--- valgrind/coregrind/vg_syscalls.c #1.56:1.57
@@ -4053,5 +4053,14 @@ PRE(statfs)
MAYBE_PRINTF("statfs ( %p, %p )\n",arg1,arg2);
SYSCALL_TRACK( pre_mem_read_asciiz, tid, "statfs(path)", arg1 );
- SYSCALL_TRACK( pre_mem_write, tid, "stat(buf)",
+ SYSCALL_TRACK( pre_mem_write, tid, "statfs(buf)",
+ arg2, sizeof(struct statfs) );
+}
+
+PRE(statfs64)
+{
+ /* int statfs64(const char *path, struct statfs *buf); */
+ MAYBE_PRINTF("statfs64 ( %p, %p )\n",arg1,arg2);
+ SYSCALL_TRACK( pre_mem_read_asciiz, tid, "statfs64(path)", arg1 );
+ SYSCALL_TRACK( pre_mem_write, tid, "statfs64(buf)",
arg2, sizeof(struct statfs) );
}
@@ -4062,4 +4071,9 @@ POST(statfs)
}
+POST(statfs64)
+{
+ VG_TRACK( post_mem_write, arg2, sizeof(struct statfs64) );
+}
+
PRE(symlink)
{
@@ -4282,4 +4296,28 @@ POST(adjtimex)
}
+PRE(clock_gettime)
+{
+ /* int clock_gettime(clockid_t clk_id, struct timespec *tp); */
+ MAYBE_PRINTF("clock_gettime(%d, %p)\n" ,arg1,arg2);
+ SYSCALL_TRACK(pre_mem_write, tid, "clock_gettime(tp)",
+ arg2, sizeof(struct timespec));
+}
+
+POST(clock_gettime)
+{
+ if (!VG_(is_kerror)(res) && res == 0)
+ VG_TRACK( post_mem_write, arg2, sizeof(struct timespec) );
+}
+
+PRE(utimes)
+{
+ /* int utimes(const char *filename, struct timeval *tvp); */
+ MAYBE_PRINTF("utimes ( %p, %p )\n", arg1,arg2);
+ SYSCALL_TRACK( pre_mem_read_asciiz, tid, "utimes(filename)", arg1 );
+ if (arg2 != (UInt)NULL)
+ SYSCALL_TRACK( pre_mem_read, tid, "utimes(tvp)", arg2,
+ sizeof(struct timeval) );
+}
+
#define SIGNAL_SIMULATION 1
@@ -4657,4 +4695,5 @@ static const struct sys_info sys_info[]
SYSBA(stat, False),
SYSBA(statfs, False),
+ SYSBA(statfs64, False),
SYSB_(symlink, True),
SYSBA(stat64, False),
@@ -4668,4 +4707,5 @@ static const struct sys_info sys_info[]
SYSBA(uname, False),
SYSB_(utime, True),
+ SYSB_(utimes, False),
SYSBA(waitpid, True),
SYSBA(wait4, True),
@@ -4673,4 +4713,5 @@ static const struct sys_info sys_info[]
SYSB_(prctl, True),
SYSBA(adjtimex, False),
+ SYSBA(clock_gettime, False),
/* new signal handling makes these normal blocking syscalls */
--- valgrind/coregrind/vg_unsafe.h #1.19:1.20
@@ -91,5 +91,6 @@
#include <sys/types.h>
-#include <sys/statfs.h>
+#include <asm/statfs.h>
+#undef statfs
#include <sys/sysinfo.h>
|
|
From: Josef W. <Jos...@gm...> - 2003-11-18 00:30:03
|
Hi, to let KCachegrind act as code coverage tool, I need a cachegrind.out file covering all instructions with source line debug info of an ELF object (say event type "DIr" for "distinct instruction fetches"). Together with real cachegrind data (i.e. type "Ir"), this can be combined to show the percentage of executed code to all code by specifying a derived cost type "(Ir>0 @Instr) / DIr". For this, I use profile data granularity at instruction level (this is an extension of the original cachegrind format). Thus, "Ir>0 @ Instr" is a threshold operator acting at instruction level, i.e. this cost metric is 1 (=true) for every instruction executed at least once. The "/" (ratio operator) is always applied last, i.e. for a file/object/function/line you get this way the ratio of all distinct instructions executed at least once to all distinct instructions of that file/... . This should be the correct notion for code coverage, shouldn't it? BTW, to get a coverage metric on line granularity, I would use "(Ir>0 @ Line) / (DIr>0 @ Line)". I just wrote a skin to get data covering the full code of an ELF object, see attached file. It is working quite fine with VG 2.0.0, but it's a little ugly as e.g. VG_(disBB) isn't exported to skins (and the structure UCodeBlock) ;-( Doing this with objdump and a small script is unfortunately not possible, as objdump can't cope with DWARF-2 debug line info (?). The file can be loaded in KCachegrind 0.4.x, but derived metrics with above operators is currently not possible. Can you comment on my approach? Note: it would be by far more efficient if there would be iterators for line debug info... Aside from that, I added event types "DInt" and "DFp" for distinct integer/ float arithmetic instructions. Unfortunately, this is totally screwed. It's not working with SSE/MMX, and even multiply is not recognized as this is translated to calls to helper functions. But events "MrSize" and "MwSize" (size of memory read/write accesses of an instruction) should be quite interesting: In combination with cachegrind data, e.g. "Dr * MrSize" gives you the amount of all memory read accesses issued by a function, and together with the cycle estimation, we get an estimation for the bandwidth. Josef |
|
From: Robert W. <rj...@ke...> - 2003-11-17 17:46:50
|
CVS commit by rjwalsh: Add a facility for tracking open file descriptors. Information about still open files is dumped out exit. Enabled using the --track-fds switch. A corecheck/tests/fdleak_cmsg.c 1.1 [POSSIBLY UNSAFE: printf] [no copyright] A corecheck/tests/fdleak_cmsg.stderr.exp 1.1 A corecheck/tests/fdleak_cmsg.vgtest 1.1 A corecheck/tests/fdleak_creat.c 1.1 [POSSIBLY UNSAFE: printf] [no copyright] A corecheck/tests/fdleak_creat.stderr.exp 1.1 A corecheck/tests/fdleak_creat.vgtest 1.1 A corecheck/tests/fdleak_dup.c 1.1 [no copyright] A corecheck/tests/fdleak_dup.stderr.exp 1.1 A corecheck/tests/fdleak_dup.vgtest 1.1 A corecheck/tests/fdleak_dup2.c 1.1 [no copyright] A corecheck/tests/fdleak_dup2.stderr.exp 1.1 A corecheck/tests/fdleak_dup2.vgtest 1.1 A corecheck/tests/fdleak_fcntl.c 1.1 [no copyright] A corecheck/tests/fdleak_fcntl.stderr.exp 1.1 A corecheck/tests/fdleak_fcntl.vgtest 1.1 A corecheck/tests/fdleak_ipv4.c 1.1 [POSSIBLY UNSAFE: printf] [no copyright] A corecheck/tests/fdleak_ipv4.stderr.exp 1.1 A corecheck/tests/fdleak_ipv4.stdout.exp 1.1 A corecheck/tests/fdleak_ipv4.vgtest 1.1 A corecheck/tests/fdleak_open.c 1.1 [no copyright] A corecheck/tests/fdleak_open.stderr.exp 1.1 A corecheck/tests/fdleak_open.vgtest 1.1 A corecheck/tests/fdleak_pipe.c 1.1 [no copyright] A corecheck/tests/fdleak_pipe.stderr.exp 1.1 A corecheck/tests/fdleak_pipe.vgtest 1.1 A corecheck/tests/fdleak_socketpair.c 1.1 [no copyright] A corecheck/tests/fdleak_socketpair.stderr.exp 1.1 A corecheck/tests/fdleak_socketpair.vgtest 1.1 A corecheck/tests/filter_fdleak 1.1 M +23 -3 corecheck/tests/Makefile.am 1.14 M +7 -0 coregrind/vg_include.h 1.155 M +16 -0 coregrind/vg_main.c 1.122 M +88 -4 coregrind/vg_mylibc.c 1.57 M +356 -7 coregrind/vg_syscalls.c 1.56 M +9 -0 coregrind/docs/coregrind_core.html 1.17 M +39 -0 include/vg_kerneliface.h 1.6 M +14 -0 include/vg_skin.h 1.100 |
|
From: Ashley P. <as...@pi...> - 2003-11-17 13:02:21
|
On Mon, 2003-11-17 at 12:24, Dirk Mueller wrote: > On Monday 17 November 2003 13:11, Ashley Pittman wrote: > > > I like it (roughly) as it is but it would be nice if the 'trimmed' > > messages contained a link to the full commit so I could read them if I > > wanted to. > > Well, the commit logs still have the information which files were modified and > which revisions there are. we have a script to generate a diff from that. You might have a script to do that but I don't, I *could* write a script to grok the email for me but it would be easier if I didn't have to. If this can't be done then I vote for a larger trim threshold. Ashley, |
|
From: Nicholas N. <nj...@ca...> - 2003-11-17 12:40:13
|
On Mon, 17 Nov 2003, Dirk Mueller wrote: > > Fair enough if you're getting commit logs for all of KDE. (People really > > do that? Wow.) > > Sure, thats the point of commit logs anyway (peer review and all that). Yeah, but particular individuals getting all logs for all of KDE? > Anyway, if you don't like the atomic commit logs at all we can just switch to > the sourceforge-style script (which exists for a far longer time than sf but > anyway). I have no complaints about the atomicity of the logs, that is a clear improvement over the SF-style logs; I just want to see all of each diff :) N |
|
From: Dirk M. <dm...@gm...> - 2003-11-17 12:30:01
|
On Monday 17 November 2003 13:15, Nicholas Nethercote wrote: > Fair enough if you're getting commit logs for all of KDE. (People really > do that? Wow.) Sure, thats the point of commit logs anyway (peer review and all that). > Assuming this is just for Valgrind commits, I say the higher the better; > the bigger it is, the more likely I want to look at it, and we don't have > many big commits. Trimming isn't important. Others may disagree. Yeah. like those complaining that they get commit logs at all :) Anyway, if you don't like the atomic commit logs at all we can just switch to the sourceforge-style script (which exists for a far longer time than sf but anyway). |
|
From: Dirk M. <dm...@gm...> - 2003-11-17 12:25:40
|
On Monday 17 November 2003 13:11, Ashley Pittman wrote: > I like it (roughly) as it is but it would be nice if the 'trimmed' > messages contained a link to the full commit so I could read them if I > wanted to. Well, the commit logs still have the information which files were modified and which revisions there are. we have a script to generate a diff from that. |
|
From: Nicholas N. <nj...@ca...> - 2003-11-17 12:16:38
|
On Mon, 17 Nov 2003, Dirk Mueller wrote: > Yeah.. The main point is that we want people involved in KDE development to be > subscribed on kde-cvs. And many claimed that they're not going to subscribe > if there are 500kb diffs appended to each mail, which is understandable, > because there is not one commit per day, or ten commits per day or even a > hundred commits per day but actually many many more. Fair enough if you're getting commit logs for all of KDE. (People really do that? Wow.) > Anyway, so I should raise the limit.. to 16kb? 160kb? 1600kb ? Assuming this is just for Valgrind commits, I say the higher the better; the bigger it is, the more likely I want to look at it, and we don't have many big commits. Trimming isn't important. Others may disagree. N |
|
From: Ashley P. <as...@pi...> - 2003-11-17 12:12:18
|
On Mon, 2003-11-17 at 11:58, Dirk Mueller wrote: > Yeah.. The main point is that we want people involved in KDE development to be > subscribed on kde-cvs. And many claimed that they're not going to subscribe > if there are 500kb diffs appended to each mail, which is understandable, > because there is not one commit per day, or ten commits per day or even a > hundred commits per day but actually many many more. But I'm not subscribed to kde-cvs, I'm subscribed to valgrind-developers so that argument is largely bogus. > Anyway, so I should raise the limit.. to 16kb? 160kb? 1600kb ? I like it (roughly) as it is but it would be nice if the 'trimmed' messages contained a link to the full commit so I could read them if I wanted to. Ashley, |
|
From: Dirk M. <dm...@gm...> - 2003-11-17 11:59:13
|
On Monday 17 November 2003 12:45, Nicholas Nethercote wrote: > see, where the commit log message isn't sufficient to understand what just > happened. Any chance of this being changed, or is it a KDE-wide thing? Sure, it can be changed when I know how it should behave.. :) > is fine. The SF.net messages did this sometimes, I think; but they never > omitted changes completely. Yeah.. The main point is that we want people involved in KDE development to be subscribed on kde-cvs. And many claimed that they're not going to subscribe if there are 500kb diffs appended to each mail, which is understandable, because there is not one commit per day, or ten commits per day or even a hundred commits per day but actually many many more. Anyway, so I should raise the limit.. to 16kb? 160kb? 1600kb ? |
|
From: Nicholas N. <nj...@ca...> - 2003-11-17 11:57:34
|
CVS commit by nethercote: Added links to the new Bugzilla page from bugs.html and features.html. M +13 -10 bugs.html 1.6 M +11 -7 features.html 1.3 --- devel-home/valgrind/bugs.html #1.5:1.6 @@ -14,8 +14,14 @@ failures people seem to encounter in practice. <p> -If that fails, send it to the valgrind-users -<a href="lists.html">mailing list</a>. We try to respond to most bug -reports, but if we don't, it doesn't mean we are ignoring you; it may -well be that the bug has been reported before. +If that fails, please file a report using our +<a href="http://bugs.kde.org/enter_valgrind_bug.cgi">Bugzilla page</a>. +Patches for bugs are particularly welcome. Please note that this +Bugzilla page is new, and there may be some teething troubles. +<p> +If you have trouble with Bugzilla, or for some reason you don't think +Bugzilla is appropriate for your report (although it probably is), +contact the valgrind-users <a href="lists.html">mailing list</a>. We +try to respond to most bug reports, but if we don't, it doesn't mean we +are ignoring you; it may well be that the bug has been reported before. <p> When you report a bug, <i>please</i> give the following information: @@ -25,11 +31,8 @@ <li>The output of <code>valgrind -v</code>. </ul> -It may also be useful to include your Linux version, kernel version, and glibc -version. If you include all this information, you are much more likely to get -a useful response. -<p> -Patches for bugs are particularly welcome. +It may also be useful to include your Linux version, kernel version, and +glibc version. If you include all this information, you are much more +likely to get a useful response. <p> -We hope to have Bugzilla set up soon to deal with bug reports. <?php --- devel-home/valgrind/features.html #1.2:1.3 @@ -9,8 +9,15 @@ <center><h2>Feature Requests</h2></center> -To request a feature, please email the valgrind-users <a -href="lists.html">mailing list</a>. We try to respond to most feature -requests, but if we don't, it doesn't mean we are ignoring you, rather -that we don't have any particular comments. +If that fails, please use our +<a href="http://bugs.kde.org/enter_valgrind_bug.cgi">Bugzilla page</a>; +make an entry with the severity "wishlist". Please note that this +Bugzilla page is new, and there may be some teething troubles. +<p> +If you have trouble with Bugzilla, or for some reason you don't think +Bugzilla is appropriate for your request (although it probably is), +contact the valgrind-users <a href="lists.html">mailing list</a>. We +try to respond to most feature requests, but if we don't, it doesn't +mean we are ignoring you, rather that we don't have any particular +comments. <p> Please note that we cannot satisfy many feature requests. A feature @@ -19,7 +26,4 @@ implementing a feature, that will help your chances too. <p> -We hope to have Bugzilla set up soon to deal with feature requests. -<p> - <?php |
|
From: Nicholas N. <nj...@ca...> - 2003-11-17 11:46:01
|
On Mon, 17 Nov 2003, Dirk Mueller wrote: > > Sometimes these log messages contain the diff, and sometimes they don't. > > Is there a reason why/why not? > > there is a diff when it is < 3kb. > > > I like seeing diffs (although I don't mind > > it if really big ones are trimmed a bit). > > Thats what it does :) We have different interpretations of "big" and "trimmed" :) 3kb is pretty small. That commit I just made was quite trivial, and it didn't make it. Changes bigger than 3kb are really the ones you want to see, where the commit log message isn't sufficient to understand what just happened. Any chance of this being changed, or is it a KDE-wide thing? As for trimming, I meant if you have 1000 removed lines, and 1000 new lines, having something like [500 removed lines skipped] is fine. The SF.net messages did this sometimes, I think; but they never omitted changes completely. N |
|
From: Dirk M. <dm...@gm...> - 2003-11-17 11:19:23
|
On Monday 17 November 2003 12:03, Nicholas Nethercote wrote: > Sometimes these log messages contain the diff, and sometimes they don't. > Is there a reason why/why not? there is a diff when it is < 3kb. > I like seeing diffs (although I don't mind > it if really big ones are trimmed a bit). Thats what it does :) |
|
From: Dirk M. <dm...@gm...> - 2003-11-17 11:19:23
|
On Monday 17 November 2003 04:00, Robert Walsh wrote: > Any idea why gcc (version 3.3.2-1) is spitting this warning out when I > compile on Fedora Core 1 (I haven't tried on anything else, btw): Because we compile with -Winline. Its not a compile error though, merely a warning. . |
|
From: Nicholas N. <nj...@ca...> - 2003-11-17 11:04:35
|
On Mon, 17 Nov 2003, Nicholas Nethercote wrote: > Made the warning clearer when you try to catch SIGKILL/SIGSTOP. Also made it > clearer what's wrong if you try to catch signals 32 and 33; they're not bad > signals, just used internally. Updated one regtest accordingly. > > > M +10 -6 corecheck/tests/sigkill.stderr.exp 1.4 > M +17 -4 coregrind/vg_signals.c 1.50 Sometimes these log messages contain the diff, and sometimes they don't. Is there a reason why/why not? I like seeing diffs (although I don't mind it if really big ones are trimmed a bit). N |