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
(22) |
2
(19) |
3
(8) |
4
(34) |
5
(14) |
6
(14) |
|
7
(12) |
8
(15) |
9
(15) |
10
(10) |
11
(10) |
12
(28) |
13
(11) |
|
14
(22) |
15
(29) |
16
(20) |
17
(15) |
18
(39) |
19
(11) |
20
(12) |
|
21
(8) |
22
(9) |
23
(8) |
24
(10) |
25
(9) |
26
(7) |
27
(7) |
|
28
(6) |
29
(6) |
30
(11) |
|
|
|
|
|
From: Jeremy F. <je...@go...> - 2004-11-23 23:57:52
|
On Sat, 2004-11-20 at 12:08 +0000, Julian Seward wrote: > I have to disagree. Having our own mini-glibc decouples us from > the vagaries of what's supplied as libc on, eg, *BSD, Solaris, AIX, > etc. If we were going to reproduce a large fraction of glibc then > it would be a liability, but we only use a small amount. I am in > favour of a "system abstraction layer" to support V's internal > activities, such as Mozilla's NPR (?) and OOo's SAL. Clearly it > would be smaller and simpler than either of those, but the > principle is the same. Most of what we have in vg_libc is either incredibly generic stuff, like str*(), or very system-dependent stuff, like syscall interfaces. The trouble is that every OS has different conventions for how syscalls are called, and how libc functions are mapped to those syscalls. That's stuff that the system libc already has and knows how to deal with. We would just have to replicate it for each system. Our libc needs are pretty generic: we're not going to have problems with a libc not having memcpy. I think using the system libcs will present less variation than the differences in the underlying kernel interfaces which they hide. > I never got the impression from user feedback that the P-clobbers-V > problem was significant. What's more, telling people to fix errors > in the order is necessary even at present: even if P does not trash > V, errors often form cascades, and it is the first one that needs > to be fixed first. The whole point is that Valgrind is for operating on programs which are assumed to be broken; assumed to be behaving in unpredictable ways. A program may work fine under memcheck but trash random addresses under helgrind. If Valgrind can't protect itself from the client, then its results will always be under a cloud. With pointercheck, I know that something is either a bug in Valgrind, or a bug in the client, but it definitely isn't the client trashing Valgrind. > > Well, hm. If Valgrind is sharing ld.so with the client, then they're > > not really separate programs at all. If the client screws up the > > dynamic linker, Valgrind could get hit and crash without being able to > > report on it at all. > > The underlying issue here is that mc/ac access control is too crude. > For a while I have been thinking about 2 A bits per byte, one for > read/exec access and one for write. Then executable areas could be > marked as readonly and the above cannot happen. I don't see how that would help. If there's one instance of ld.so, then there's one set of datastructures. Sometimes those structures will be manipulated by the client, with ld.so running on the virtual CPU, and sometimes running on the real CPU as part of Valgrind. I don't see how you could set up a permissions system which allows those structures to be manipulated correctly but never trashed by the client. > It would also finally > give us Robert's memory watchpoints for free. Well, at the cost of increasing the virtual address space pressure, which apparently is a significant problem. > I never understood why we care about statically linked executables. > My view is they are a special-case anomaly which it is not worth supporting. > No developer doing day-to-day hacking is going to continually be building > statically linked executables (are they?) IMO just detecting them and > stopping with a warning is good enough. They're useful for people doing embedded stuff. You can link an RTOS with an app into a simulation environment and run it as a normal process. > > > - Also, the inflexibility of the memory layout has caused many problems: > > > - difficulties for non-standard (ie. 3G:1G) kernels > > > - can't run with a virtual memory ulimit (bad esp. for embedded > > > developers) > > > > Can you explain? What do you mean by "embedded developers"? The > > I guess, developers operating in scenarios with small amounts of > virtual memory? Embedded systems normally have a problem of not enough physical memory, which is unaffected by any of these proposls. If they're running Linux on an x86, then there's no particular reason they'd have limited virtual space. The virtual ulimit is only useful for stopping a runaway program from generating a thrash storm, and only under a very limited number of cases (since it only affects the brk syscall, and not mmap). > > > - V and P mappings are totally intermingled. We just let the kernel > > > mmap things wherever it wants, without trying to enforce any layout > > > ourselves. (This precludes big-bang shadow allocation, and thus > > > precludes fixed-offset shadow memory addressing being used in the > > > future. This does not worry me.) This makes startup much easier, > > > since we don't have to be so careful about where things go. > > > > ... > > I guess my OS/kernel background is really making me dislike this idea. > > Uh ... you need to say *why* you dislike the idea. Why? Well, from an OS perspective, having a kernel which protects itself from buggy application code is what marks the difference from a real OS and a piece of unreliable junk. Unprotected operating systems work with the charming naievety that all application code is basically bug-free and won't cause any damage. Since in Valgrind we know the client code is buggy, probably with some kind of memory problem, we know there's a good likelihood that the client is going to start taking pot-shots at the core. If we're lucky, it will do it when we're running under addr/memcheck. If not, it will quietly corrupt things when we're using some other tool. And I know, heisenbugs which appear under some tools but not other are an orthogonal problem which is generally unsolvable, but FV makes checking for the wildest memory access problems pretty cheap, and it also means that Valgrind's memory allocation patterns have less/no effect on the client allocation layout. > The new VCPU (VEX) provides precise (memory) exceptions if you need > them. Good. > :-) the obsolete systems are going to be around for a *long* time > yet :-) and will probably always be the majority. Yes, 64-bit machines are already becoming pretty common, and will be a more attractive machine for hosting Valgrind sessions than 32-bit machines. In other words, in the total population of systems I agree with you, but in the world of developers-using-Valgrind, I think 64-bit systems will be much more common. J |
|
From: Richard v. d. H. <ric...@mx...> - 2004-11-23 21:23:19
|
Richard van der Hoff wrote: > I've been doing some work on tracking down an assertion failure with > Helgrind, and it turns out to be thrown whenever vgPlain_sprintf() is > called with a %y conversion - because the %y conversion uses sprintf > itself. > ... > Let's try the attached patch against CVS HEAD - unfortunately there > are a few more changes, but it does fix it properly in a thread-safe > kind of way. Sorry to pester, but would it be possible to have the patch applied, or at least have some feedback, before it goes stale? I'm aware that things are busy at the moment, and that whether this code would even be in the next major release is currently questionable; however, I hope that this patch is pretty safe and should apply easily at the moment, and it would make my list of things-to-remember shorter if this fix made it into CVS. Cheers, -- Richard van der Hoff <ric...@mx...> Systems Analyst Tel: +44 (0) 845 666 7778 http://www.mxtelecom.com |
|
From: Robert W. <rj...@du...> - 2004-11-23 20:29:53
|
CVS commit by rjwalsh:
Fix fcntl to only check arg3 when it's actually used.
fixes bug 93810.
M +34 -4 coregrind/vg_syscalls.c 1.226
M +5 -2 include/x86-linux/vki_arch.h 1.8
--- valgrind/coregrind/vg_syscalls.c #1.225:1.226
@@ -1927,6 +1927,21 @@ PRE(sys_fcntl, 0)
{
PRINT("sys_fcntl ( %d, %d, %d )", arg1,arg2,arg3);
+ switch(arg2) {
+ case VKI_F_DUPFD:
+ case VKI_F_SETFD:
+ case VKI_F_SETFL:
+ case VKI_F_GETLK:
+ case VKI_F_SETLK:
+ case VKI_F_SETLKW:
+ case VKI_F_SETOWN:
+ case VKI_F_SETSIG:
+ case VKI_F_SETLEASE:
PRE_REG_READ3(long, "fcntl",
unsigned int, fd, unsigned int, cmd, unsigned long, arg);
+ break;
+ default:
+ PRE_REG_READ2(long, "fcntl",
+ unsigned int, fd, unsigned int, cmd);
+ }
if (arg2 == VKI_F_SETLKW)
tst->sys_flags |= MayBlock;
@@ -1976,6 +1991,21 @@ PRE(sys_fcntl64, 0)
{
PRINT("sys_fcntl64 ( %d, %d, %d )", arg1,arg2,arg3);
+ switch(arg2) {
+ case VKI_F_DUPFD:
+ case VKI_F_SETFD:
+ case VKI_F_SETFL:
+ case VKI_F_GETLK:
+ case VKI_F_SETLK:
+ case VKI_F_SETLKW:
+ case VKI_F_SETOWN:
+ case VKI_F_SETSIG:
+ case VKI_F_SETLEASE:
PRE_REG_READ3(long, "fcntl64",
unsigned int, fd, unsigned int, cmd, unsigned long, arg);
+ break;
+ default:
+ PRE_REG_READ2(long, "fcntl64",
+ unsigned int, fd, unsigned int, cmd);
+ }
if (arg2 == VKI_F_SETLKW || arg2 == VKI_F_SETLKW64)
tst->sys_flags |= MayBlock;
--- valgrind/include/x86-linux/vki_arch.h #1.7:1.8
@@ -280,7 +280,10 @@ struct vki_sigcontext {
#define VKI_F_GETFL 3 /* get file->f_flags */
#define VKI_F_SETFL 4 /* set file->f_flags */
-//#define VKI_F_GETLK 5
-//#define VKI_F_SETLK 6
+#define VKI_F_GETLK 5
+#define VKI_F_SETLK 6
#define VKI_F_SETLKW 7
+#define VKI_F_SETOWN 8
+#define VKI_F_SETSIG 10
+#define VKI_F_SETLEASE 1024
#define VKI_F_SETLKW64 14
|
|
From: Tom H. <to...@co...> - 2004-11-23 03:25:49
|
Nightly build on dunsmere ( Fedora Core 3 ) started at 2004-11-23 03:20:04 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 191 tests, 12 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/badpoll (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/execve2 (stderr) memcheck/tests/scalar (stderr) memcheck/tests/scalar_exit_group (stderr) memcheck/tests/scalar_supp (stderr) memcheck/tests/writev (stderr) none/tests/exec-sigmask (stdout) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-11-23 03:20:50
|
Nightly build on audi ( Red Hat 9 ) started at 2004-11-23 03:15:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 191 tests, 12 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/badpoll (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/execve2 (stderr) memcheck/tests/scalar (stderr) memcheck/tests/scalar_exit_group (stderr) memcheck/tests/scalar_supp (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-11-23 03:12:13
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2004-11-23 03:10:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow gcc -Winline -Wall -Wshadow -g -o metadata metadata.o source='threadederrno.c' object='threadederrno.o' libtool=no \ depfile='.deps/threadederrno.Po' tmpdepfile='.deps/threadederrno.TPo' \ depmode=gcc3 /bin/sh ../../depcomp \ gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../include -Winline -Wall -Wshadow -g -c `test -f 'threadederrno.c' || echo './'`threadederrno.c gcc -Winline -Wall -Wshadow -g -o threadederrno threadederrno.o -lpthread source='vgtest_ume.c' object='vgtest_ume.o' libtool=no \ depfile='.deps/vgtest_ume.Po' tmpdepfile='.deps/vgtest_ume.TPo' \ depmode=gcc3 /bin/sh ../../depcomp \ gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../include -Winline -Wall -Wshadow -g -c `test -f 'vgtest_ume.c' || echo './'`vgtest_ume.c cc1: No space left on device: error writing to /tmp/cc1ln4hQ.s make[4]: *** [vgtest_ume.o] Error 1 make[4]: Leaving directory `/tmp/valgrind.18138/valgrind/memcheck/tests' make[3]: *** [check-am] Error 2 make[3]: Leaving directory `/tmp/valgrind.18138/valgrind/memcheck/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/valgrind.18138/valgrind/memcheck/tests' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.18138/valgrind/memcheck' make: *** [check-recursive] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-11-23 03:08:41
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2004-11-23 03:05:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_fpu: valgrind ./insn_fpu insn_mmx: valgrind ./insn_mmx insn_mmxext: valgrind ./insn_mmxext insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int rm: cannot remove `vgcore.pid*': No such file or directory (cleanup operation failed: rm vgcore.pid*) pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 191 tests, 2 stderr failures, 0 stdout failures ================= memcheck/tests/scalar (stderr) memcheck/tests/vgtest_ume (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-11-23 03:04:23
|
Nightly build on standard ( Red Hat 7.2 ) started at 2004-11-23 03:00:01 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_fpu: valgrind ./insn_fpu insn_mmx: valgrind ./insn_mmx insn_mmxext: valgrind ./insn_mmxext insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int rm: cannot remove `vgcore.pid*': No such file or directory (cleanup operation failed: rm vgcore.pid*) pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 191 tests, 2 stderr failures, 0 stdout failures ================= memcheck/tests/scalar (stderr) memcheck/tests/vgtest_ume (stderr) make: *** [regtest] Error 1 |