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
|
2
|
3
(1) |
4
|
|
5
(1) |
6
|
7
|
8
(1) |
9
|
10
(1) |
11
|
|
12
|
13
|
14
(1) |
15
(2) |
16
|
17
|
18
|
|
19
(3) |
20
(2) |
21
(7) |
22
(9) |
23
(2) |
24
|
25
|
|
26
|
27
|
28
(3) |
29
(2) |
30
(16) |
31
(3) |
|
|
From: Jeremy F. <je...@go...> - 2003-10-30 16:24:23
|
We're seeing a few cases of build failures in and around vg_unsafe.h. It is considered generally bad form to include linux/* or asm/* directly in a user-space program. Valgrind doesn't quite count as a normal user-space program, but there's no way of telling the compiler that. I think the easiest solution might be to just keep of a copy of the kernel headers we're actually using in our source. That, or just extend vg_kernelinterface.h a fair amount. Comments? J |
|
From: Dirk M. <mu...@kd...> - 2003-10-30 13:50:07
|
CVS commit by mueller:
there have been reports that "stat" is not portable enough.
MERGE TO STABLE
M +10 -9 valgrind.in 1.36
--- valgrind/coregrind/valgrind.in #1.35:1.36
@@ -131,16 +131,17 @@
echo "to work with it. Read FAQ #5 for more information."
exit 1 ;;
+ # ensure that there are no setuid or gid flags
+ *:\ set?id\ ELF*)
+ 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."
+ echo ""
+ echo "Remove those flags and try again."
+ echo ""
+ exit 1
+ ;;
esac
fi
- # Ensure that there is no suid or sgid flag
- if [ `stat -c %a "$which_prog"` -gt 2000 ] ; then
- 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."
- echo ""
- echo "Remove those flags and try again."
- exit 1
- fi
is_prog=1
fi
|
|
From: Dirk M. <mu...@kd...> - 2003-10-30 13:42:05
|
CVS commit by mueller: for some reason I need that to make it compile on suse 9 MERGE TO STABLE M +1 -1 vg_unsafe.h 1.18 --- valgrind/coregrind/vg_unsafe.h #1.17:1.18 @@ -38,5 +38,5 @@ #include <sys/utsname.h> /* for uname */ #include <sys/time.h> /* for struct timeval & struct timezone */ -#ifdef KERNEL_2_6 +#if defined(KERNEL_2_6) || defined(KERNEL_2_4) /* ugly hack to avoid that kernel headers redefine stuff from sys/time.h */ #define _LINUX_TIME_H |
|
From: Dirk M. <mu...@kd...> - 2003-10-30 13:31:49
|
CVS commit by mueller:
make it really silent
M +1 -1 valgrind.in 1.35
--- valgrind/coregrind/valgrind.in #1.34:1.35
@@ -105,5 +105,5 @@
# an environment variable.
-if getconf GNU_LIBPTHREAD_VERSION | grep -qi NPTL 2>/dev/null; then
+if getconf GNU_LIBPTHREAD_VERSION 2>/dev/null | grep -qi NPTL 2>/dev/null; then
LD_ASSUME_KERNEL=2.4.1
export LD_ASSUME_KERNEL
|
|
From: Josef W. <Jos...@gm...> - 2003-10-30 13:00:05
|
On Thursday 30 October 2003 13:37, Nicholas Nethercote wrote: > On Thu, 30 Oct 2003, Josef Weidendorfer wrote: > > I have no problem with this semantic change of return codes > > (libc vs. kernel). But this is a source incompatible change in the > > skin API. Can we raise the skin major version for it? > > Done. > > I think it makes sense to change the major version number only once > between each "release". Eg., if a release is made, and then two, > separate, incompatible changes are made before the next release, only > change the version number once. Thus external skins would be targetted to > match official "releases" (by "release" I guess that means any time Julian > puts up a new tarball on the website). Does this seem reasonable? Of course. I almost added something like this to the last mail. If somebody is using VG CVS, he's always on his own. Josef |
|
From: Nicholas N. <nj...@ca...> - 2003-10-30 12:37:47
|
On Thu, 30 Oct 2003, Josef Weidendorfer wrote: > I have no problem with this semantic change of return codes > (libc vs. kernel). But this is a source incompatible change in the > skin API. Can we raise the skin major version for it? Done. I think it makes sense to change the major version number only once between each "release". Eg., if a release is made, and then two, separate, incompatible changes are made before the next release, only change the version number once. Thus external skins would be targetted to match official "releases" (by "release" I guess that means any time Julian puts up a new tarball on the website). Does this seem reasonable? N |
|
From: Nicholas N. <nj...@ca...> - 2003-10-30 12:35:19
|
CVS commit by nethercote:
Increased the skin major version number, to reflect the changed return values
of functions like VG_(open), and also to cover any future changes between now
and the HEAD becoming an official release.
M +1 -1 vg_skin.h 1.97
--- valgrind/include/vg_skin.h #1.96:1.97
@@ -117,5 +117,5 @@ typedef unsigned char Bool;
will abort. The minor version indicates binary-compatible changes.
*/
-#define VG_CORE_INTERFACE_MAJOR_VERSION 3
+#define VG_CORE_INTERFACE_MAJOR_VERSION 4
#define VG_CORE_INTERFACE_MINOR_VERSION 0
|
|
From: Josef W. <Jos...@gm...> - 2003-10-30 12:31:10
|
Ok. I have no problem with this semantic change of return codes (libc vs. kernel). But this is a source incompatible change in the skin API. Can we raise the skin major version for it? Josef On Thursday 30 October 2003 11:35, Nicholas Nethercote wrote: > On Thu, 30 Oct 2003, Jeremy Fitzhardinge wrote: > > No. strace is (somewhat) lying - the syscall is returning -2, not -1. > > If you were using libc, then open() would return -1 and set errno to 2 > > (ENOENT). But since we're going straight to the kernel and don't have > > errno, VG_(open) is directly returning the negative error code (-2 == > > ENOENT). > > The different views of syscalls -- glibc's view vs. the kernel's view -- > has tripped me up before. Generally, the kernel returns a negative error > value, and then glibc puts that in errno (but positive), and returns -1 > from the call. There are some cases where the kernel vs. glibc difference > is bigger -- I think mmap, brk and getcwd are examples. > > N > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Nicholas N. <nj...@ca...> - 2003-10-30 10:35:36
|
On Thu, 30 Oct 2003, Jeremy Fitzhardinge wrote: > No. strace is (somewhat) lying - the syscall is returning -2, not -1. > If you were using libc, then open() would return -1 and set errno to 2 > (ENOENT). But since we're going straight to the kernel and don't have > errno, VG_(open) is directly returning the negative error code (-2 == > ENOENT). The different views of syscalls -- glibc's view vs. the kernel's view -- has tripped me up before. Generally, the kernel returns a negative error value, and then glibc puts that in errno (but positive), and returns -1 from the call. There are some cases where the kernel vs. glibc difference is bigger -- I think mmap, brk and getcwd are examples. N |
|
From: Nicholas N. <nj...@ca...> - 2003-10-30 10:34:07
|
CVS commit by nethercote:
Fix cachegrind to deal with VG_(open)() returning any negative number on error,
not just -1.
M +1 -1 cg_main.c 1.54
--- valgrind/cachegrind/cg_main.c #1.53:1.54
@@ -1620,5 +1620,5 @@ static void fprint_BBCC_table_and_calc_t
fd = VG_(open)(cachegrind_out_file, VKI_O_CREAT|VKI_O_TRUNC|VKI_O_WRONLY,
VKI_S_IRUSR|VKI_S_IWUSR);
- if (-1 == fd) {
+ if (fd < 0) {
/* If the file can't be opened for whatever reason (conflict
between multiple cachegrinded processes?), give up now. */
|
|
From: Jeremy F. <je...@go...> - 2003-10-30 10:25:37
|
On Thu, 2003-10-30 at 02:01, Josef Weidendorfer wrote:
> I just checked my skin with Valgrind CVS and Suse 9.0,
> and now I have the problem that the skin doesn't generate
> dumps any more.
Sorry, I changed the return code for VG_(open)() so it returns -ve error
code (errno) rather than simply -1. You can either use "if (fd < 0)" or
maybe something like "if (fd == -VKI_EEXIST) { ... } else { ... }".
> getpid() = 13270
> open("/home/weidendo/dumps/cachegrind.out.13270", O_WRONLY|O_TRUNC) = -1 ENOENT (No such file or directory)
> close(-2) = -1 EBADF (Bad file descriptor)
>
> Obviously, strace correctly gives back -1 for
> fd = VG_(open)(filename, VKI_O_WRONLY|VKI_O_TRUNC, 0);
> but my skin gets -2 (Ok, that's a small bug to call close(-2), but still...).
> But it should get -1, too ?!?
No. strace is (somewhat) lying - the syscall is returning -2, not -1.
If you were using libc, then open() would return -1 and set errno to 2
(ENOENT). But since we're going straight to the kernel and don't have
errno, VG_(open) is directly returning the negative error code (-2 ==
ENOENT).
J
|
|
From: Josef W. <Jos...@gm...> - 2003-10-30 10:02:01
|
Hi,
I just checked my skin with Valgrind CVS and Suse 9.0,
and now I have the problem that the skin doesn't generate
dumps any more.
I have in SK_(post_clo_init):
...
VG_(sprintf)(filename, "%s.%d", dump_file_base, VG_(getpid)());
fd = VG_(open)(filename, VKI_O_WRONLY|VKI_O_TRUNC, 0);
if (-1 == fd) {
fd = VG_(open)(filename, VKI_O_CREAT|VKI_O_WRONLY,
VKI_S_IRUSR|VKI_S_IWUSR);
if (-1 == fd) {
file_err();
}
}
VG_(close)(fd);
...
to truncate/create the dump file.
With strace, I see this for this part of code:
getpid() = 13270
open("/home/weidendo/dumps/cachegrind.out.13270", O_WRONLY|O_TRUNC) = -1
ENOENT
(No such file or directory)
close(-2) = -1 EBADF (Bad file descriptor)
Obviously, strace correctly gives back -1 for
fd = VG_(open)(filename, VKI_O_WRONLY|VKI_O_TRUNC, 0);
but my skin gets -2 (Ok, that's a small bug to call close(-2), but still...).
But it should get -1, too ?!?
Josef
|
|
From: Nicholas N. <nj...@ca...> - 2003-10-30 09:38:17
|
CVS commit by nethercote:
Previously, if the command given to Valgrind didn't exist, the 'stat -c'
suid/sgid test failed, and the startup script aborted with an ugly message.
I've changed it so that it first checks that the program exists in the user's
path (as determined by 'which'), and aborts if not.
This was quite fiddly to get right; yell if I've broken anything.
M +37 -24 valgrind.in 1.34
--- valgrind/coregrind/valgrind.in #1.33:1.34
@@ -110,26 +110,38 @@
fi
-which_prog="`which $1`"
+# Check that the program looks ok
+is_prog=0
-# Ensure the program isn't statically linked.
if [ $# != 0 ] ; then
- case `file "$which_prog"` in
- *"statically linked"*)
- echo "\`$which_prog' is statically linked"
- echo "Valgrind only works on dynamically linked executables; your"
- echo "program must rely on at least one shared object for Valgrind"
- echo "to work with it. Read FAQ #5 for more information."
- exit 1 ;;
- esac
-fi
-# Ensure that there is no suid or sgid flag
-if [ `stat -c %a "$which_prog"` -gt 2000 ] ; then
- 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."
- echo ""
- echo "Remove those flags and try again."
- exit 1
+ # Ensure the program exists. Ignore any error messages from 'which'.
+ which_prog=`which $1 2> /dev/null`
+ if [ z$which_prog = z ] ; then
+ echo "'$1' not found in \$PATH, aborting."
+ exit
+ fi
+
+ # Ensure the program isn't statically linked.
+ if [ $# != 0 ] ; then
+ case `file "$which_prog"` in
+ *"statically linked"*)
+ echo "\`$which_prog' is statically linked"
+ echo "Valgrind only works on dynamically linked executables; your"
+ echo "program must rely on at least one shared object for Valgrind"
+ echo "to work with it. Read FAQ #5 for more information."
+ exit 1 ;;
+ esac
+ fi
+
+ # Ensure that there is no suid or sgid flag
+ if [ `stat -c %a "$which_prog"` -gt 2000 ] ; then
+ 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."
+ echo ""
+ echo "Remove those flags and try again."
+ exit 1
+ fi
+ is_prog=1
fi
@@ -150,11 +162,12 @@
#export LD_DEBUG
-# If no command given, act like -h was given so vg_main.c prints out
-# the usage string. And pass to 'exec' tha name of any program -- it doesn't
-# matter which -- because it won't be run anyway (we use 'true').
-if [ $# != 0 ] ; then
+# Actually run the program, under Valgrind's control
+if [ $is_prog = 1 ] ; then
exec "$@"
else
- VG_ARGS="$VG_ARGS -h"
+ # If no command given, act like -h was given so vg_main.c prints out the
+ # usage string. And pass to 'exec' the name of any program -- it doesn't
+ # matter which -- because it won't be run anyway (we use 'true').
+ VG_ARGS="$VG_ARGS -h"
exec true
fi
|
|
From: Nicholas N. <nj...@ca...> - 2003-10-30 09:11:33
|
CVS commit by nethercote:
Added a regtest that uses pthreads -- there weren't any.
A pth_once.stderr.exp 1.1
A pth_once.stdout.exp 1.1
A pth_once.vgtest 1.1
M +1 -0 Makefile.am 1.29
--- valgrind/memcheck/tests/Makefile.am #1.28:1.29
@@ -45,4 +45,5 @@
null_socket.stderr.exp null_socket.vgtest \
overlap.stderr.exp overlap.stdout.exp overlap.vgtest \
+ pth_once.stderr.exp pth_once.stdout.exp pth_once.vgtest \
pushfpopf.stderr.exp pushfpopf.stdout.exp pushfpopf.vgtest \
realloc1.stderr.exp realloc1.vgtest \
|
|
From: Jeremy F. <je...@go...> - 2003-10-30 07:45:27
|
CVS commit by fitzhardinge: Add a --assume-2.4=yes|no CLO. This overrides the normal check to see if the kernel has enough capabilities to run in 2.6 mode (ie, futex, the right kind of clone, correct signal handling properties), and always uses 2.4 mode. This will often not work on a 2.6 or RH9 2.4 kernel, but it does help avoid a bug in the SuSE 8.2 (and possibly 9) kernels, which look like they support enough to run in 2.6 mode, but get it wrong. TODO: make the startup script/configure actually use this option. Also some cleanup in printing debugging messages from vg_proxylwp.c, and a small fix in the handling of ERESTARTSYS (assume that every syscall will get interrupted from the outset, until it actually completes). M +2 -0 vg_include.h 1.151 M +9 -0 vg_main.c 1.118 M +24 -13 vg_proxylwp.c 1.2 |
|
From: Jeremy F. <je...@go...> - 2003-10-30 07:44:45
|
CVS commit by fitzhardinge: Update some stuff related to the syscalls change: - restart syscalls which return ERESETARTSYS - make code to restart a syscall common - keep a process-wide pending signal set to store as-yet undelivered signals (only used in 2.4 mode; TODO: siginfo, queues) - make execve work a bit better - it is impossible to recover from execve failing, so we try to check that it will before running the syscall itself (also fixes bug with SuSE 8.2 kernel) M +1 -0 coregrind/vg_include.h 1.150 M +1 -1 coregrind/vg_mylibc.c 1.55 M +40 -52 coregrind/vg_signals.c 1.47 M +60 -12 coregrind/vg_syscalls.c 1.51 M +1 -0 include/vg_kerneliface.h 1.4 M +1 -1 include/vg_skin.h 1.96 |