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
(15) |
2
(12) |
3
(11) |
4
(20) |
5
(6) |
|
6
(6) |
7
(7) |
8
(8) |
9
(17) |
10
(25) |
11
(27) |
12
(6) |
|
13
(28) |
14
(16) |
15
(20) |
16
(9) |
17
(26) |
18
(7) |
19
(25) |
|
20
(7) |
21
(18) |
22
(25) |
23
(15) |
24
(21) |
25
(32) |
26
(15) |
|
27
(23) |
28
(33) |
|
|
|
|
|
|
From: Nicholas N. <nj...@cs...> - 2005-02-13 18:42:23
|
Hi,
I'm trying to get self-hosting to work on my machine. I just switched to
recent versions of gcc (3.4.3) and ld (binutils 2.15) which support PIE.
But once I built Valgrind, I get a seg fault at startup. Diagnostic printfs
tell me that things are ok until at least the just before the call to
jmp_with_stack() at the end of stage1.c:main2(). But the seg fault
manifests before the first statement in vg_main.c:main() executes.
The distro on the machine is an oldish Debian one; in particular the glibc
version is 2.2.5:
[~/grind/head2] /lib/libc.so.6
GNU C Library stable release version 2.2.5, by Roland McGrath et al.
Copyright (C) 1992-2001, 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 2.95.4 20011002 (Debian prerelease).
Compiled on a Linux 2.4.18 system on 2005-01-07.
Available extensions:
GNU libio by Per Bothner
crypt add-on version 2.1 by Michael Glad and others
linuxthreads-0.9 by Xavier Leroy
BIND-8.2.3-T5B
libthread_db work sponsored by Alpha Processor Inc
NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
Report bugs using the `glibcbug' script to <bu...@gn...>.
Is it possible that the dynamic linker is too old to handle PIE executables?
But a toy program compiled with "gcc -fpie a.c" worked ok.
Kernel version is 2.4.29, in case that's relevant:
[~/grind/head2] uname -a
Linux charco.cs.utexas.edu 2.4.29 #1 SMP Mon Jan 24 09:20:36 CST 2005 i686
unknown
Valgrind was working fine with older, non-PIE versions of gcc and ld.
Any suggestions what the problem might be, or how to hunt it down? Thanks.
N
|
|
From: Nicholas N. <nj...@cs...> - 2005-02-13 17:50:40
|
CVS commit by nethercote:
Fix old comment.
M +1 -1 vg_regtest.in 1.30
--- valgrind/tests/vg_regtest.in #1.29:1.30
@@ -281,5 +281,5 @@
# Pass the appropriate --tool option for the directory (can be overridden
- # by an "args:" or "args.dev:" line, though).
+ # by an "args:" line, though).
my $tool=determine_tool();
mysystem("VALGRINDLIB=$tests_dir/.in_place $valgrind --command-line-only=yes --tool=$tool $vgopts $prog $args > $name.stdout.out 2> $name.stderr.out");
|
|
From: Nicholas N. <nj...@cs...> - 2005-02-13 17:42:33
|
On Sun, 13 Feb 2005, Tom Hughes wrote: >> VG_(get_memory_from_mmap): newSuperblock's request for 1048576 bytes failed. >> VG_(get_memory_from_mmap): 33599270 bytes already allocated. >> >> Sorry. You could try using a tool that uses less memory; >> eg. addrcheck instead of memcheck. > > That usually just means your program is too big for valgrind > to cope with and it ran out of memory trying to load the debug > information or something. But 33MB isn't very much memory, so something else must be going wrong... N |
|
From: Tom H. <th...@cy...> - 2005-02-13 17:19:56
|
CVS commit by thughes:
Add some more _dl_relocate_* suppressions.
M +5 -1 glibc-2.2.supp 1.32
M +7 -0 glibc-2.3.supp 1.22
--- valgrind/glibc-2.2.supp #1.31:1.32
@@ -66,5 +66,9 @@
fun:_dl_catch_error*
}
-
+{
+ _dl_relocate_object_internal
+ Memcheck:Cond
+ fun:_dl_relocate_object_internal
+}
#-------- SuSE 8.1 stuff (gcc-3.2, glibc-2.2.5 + SuSE's hacks)
--- valgrind/glibc-2.3.supp #1.21:1.22
@@ -129,4 +129,11 @@
}
+#-------- glibc 2.3.4/ Fedora Core 3
+{
+ dl_relocate_object
+ Memcheck:Cond
+ fun:_dl_relocate_object
+}
+
#-------- Data races
{
|
|
From: Tom H. <th...@cy...> - 2005-02-13 16:57:55
|
CVS commit by thughes:
Add some more pthread suppressions.
M +7 -0 glibc-2.2.supp 1.31
M +8 -0 glibc-2.3.supp 1.21
--- valgrind/glibc-2.2.supp #1.30:1.31
@@ -487,2 +487,9 @@
fun:pthread_create@@GLIBC_2.1
}
+{
+ LinuxThreads: write/pthread_create
+ Memcheck:Param
+ write(buf)
+ fun:write
+ fun:pthread_create@@GLIBC_2.1
+}
--- valgrind/glibc-2.3.supp #1.20:1.21
@@ -337,4 +337,12 @@
}
+{
+ LinuxThreads: write/pthread_create
+ Memcheck:Param
+ write(buf)
+ fun:write
+ fun:pthread_create
+}
+
##----------------------------------------------------------------------##
## glibc-2.3.4 on FC3
|
|
From: Tom H. <th...@cy...> - 2005-02-13 16:43:21
|
CVS commit by thughes:
Fix the scalar test to allow munlockall to fail with EPERM and
set_tid_address to fail with ENOSYS which they do on some systems.
M +2 -2 scalar.c 1.53
M +12 -0 scalar.h 1.5
--- valgrind/memcheck/tests/scalar.c #1.52:1.53
@@ -669,5 +669,5 @@ int main(void)
// __NR_munlockall 153
GO(__NR_munlockall, "0s 0m");
- SY(__NR_munlockall); SUCC;
+ SY(__NR_munlockall); SUCC_OR_FAILx(EPERM);
// __NR_sched_setparam 154
@@ -1118,5 +1118,5 @@ int main(void)
// __NR_set_tid_address 258
GO(__NR_set_tid_address, "1s 0m");
- SY(__NR_set_tid_address, x0); SUCC;
+ SY(__NR_set_tid_address, x0); SUCC_OR_FAILx(ENOSYS);
// __NR_timer_create 259
--- valgrind/memcheck/tests/scalar.h #1.4:1.5
@@ -48,2 +48,14 @@ extern long int syscall (long int __sysn
} while (0);
+#define SUCC_OR_FAILx(E) \
+ do { \
+ int myerrno = errno; \
+ if (-1 == res) { \
+ if (E == myerrno) { \
+ /* as expected */ \
+ } else { \
+ fprintf(stderr, "Expected error %s (%d), got %d\n", #E, E, myerrno); \
+ exit(1); \
+ } \
+ } \
+ } while (0);
|
|
From: Nicholas N. <nj...@cs...> - 2005-02-13 16:17:09
|
CVS commit by nethercote: Added Lava. M +4 -0 users.html 1.79 --- devel-home/valgrind/users.html #1.78:1.79 @@ -236,4 +236,8 @@ <dt><a href="http://www.cyberscience.com/cyberscreen.html">Cyberscreen</a> <dd>A fourth generation language and rapid application development environment. + +<dt><a href="http://lavape.sourceforge.net">Lava</a> +<dd>An experimental OO programming language implementaion, including a + structure editor. </dl> |
|
From: Tom H. <th...@cy...> - 2005-02-13 15:54:57
|
CVS commit by thughes: Match filenames even more generally and change results which match against __libc_start_main so that they match the new output. M +1 -1 corecheck/tests/fdleak_creat.stderr.exp 1.5 M +2 -2 corecheck/tests/fdleak_dup.stderr.exp 1.5 M +3 -3 corecheck/tests/fdleak_dup2.stderr.exp 1.5 M +1 -1 corecheck/tests/fdleak_fcntl.stderr.exp 1.5 M +1 -1 corecheck/tests/fdleak_open.stderr.exp 1.5 M +2 -2 corecheck/tests/fdleak_pipe.stderr.exp 1.5 M +2 -2 corecheck/tests/fdleak_socketpair.stderr.exp 1.5 M +2 -2 memcheck/tests/badjump.stderr.exp 1.10 M +1 -1 memcheck/tests/badjump2.stderr.exp 1.2 M +2 -2 memcheck/tests/buflen_check.stderr.exp 1.11 M +1 -1 memcheck/tests/fwrite.stderr.exp 1.11 M +702 -702 memcheck/tests/scalar.stderr.exp 1.45 M +1 -1 memcheck/tests/scalar_exit_group.stderr.exp 1.3 M +3 -3 memcheck/tests/scalar_supp.stderr.exp 1.3 M +1 -1 memcheck/tests/weirdioctl.stderr.exp 1.10 M +1 -1 tests/filter_libc 1.4 |
|
From: Tom H. <th...@cy...> - 2005-02-13 15:49:30
|
CVS commit by thughes:
Match a wider range of characters in filenames.
M +1 -1 filter_libc 1.3
--- valgrind/tests/filter_libc #1.2:1.3
@@ -19,5 +19,5 @@
s/\(within \/.*libc.*\)$/(within \/...libc...)/;
- s/($libc_symbols) \([a-z]+\.[cS]:\d+\)$/$1 (in \/...libc...)/;
+ s/($libc_symbols) \(\w+\.[cS]:\d+\)$/$1 (in \/...libc...)/;
print;
|
|
From: Tom H. <th...@cy...> - 2005-02-13 15:47:44
|
CVS commit by thughes:
Supress any source file name for __libc_start_main.
M +2 -4 filter_libc 1.2
--- valgrind/tests/filter_libc #1.1:1.2
@@ -3,5 +3,6 @@
use strict;
-my @libc_symbols = qw(accept execve fcntl getsockname poll readv recvmsg
+my @libc_symbols = qw(__libc_start_main accept execve fcntl
+ getsockname poll readv recvmsg
socket socketpair syscall writev);
@@ -18,7 +19,4 @@
s/\(within \/.*libc.*\)$/(within \/...libc...)/;
-# s/\(\.\.\/sysdeps\/unix\/sysv\/linux\/.*\.c:\d+\)/(in \/...libc...)/;
-# s/__libc_(.*) \(.*\)$/__libc_$1 (...libc...)/;
-
s/($libc_symbols) \([a-z]+\.[cS]:\d+\)$/$1 (in \/...libc...)/;
|
|
From: Tom H. <th...@cy...> - 2005-02-13 15:45:31
|
CVS commit by thughes:
Move all the existing filters designed to canonicalise libc stack traces
into a single generic libc filter which is invoked from the basic stderr
filter so that it is applied everywhere.
The new filter also has a list of symbols whose source will be messages
to /...libc... if full debugging information was available and a source
file and line number appeared in the output.
A tests/filter_libc 1.1
M +0 -9 corecheck/tests/filter_fdleak 1.4
M +1 -14 memcheck/tests/filter_stderr 1.12
M +1 -4 none/tests/filter_stderr 1.8
M +3 -4 tests/filter_stderr_basic 1.20
--- valgrind/corecheck/tests/filter_fdleak #1.3:1.4
@@ -13,13 +13,4 @@
$dir/../../tests/filter_test_paths |
-# Anonymise paths like "(in /foo/bar/libc-baz.so)"
-sed "s/(in \/.*libc.*)$/(in \/...libc...)/" |
-
-# Anonymise paths like "xxx (../sysdeps/unix/sysv/linux/quux.c:129)"
-sed "s/(\.\.\/sysdeps\/unix\/sysv\/linux\/.*\.c:[0-9]*)$/(in \/...libc...)/" |
-
-# Anonymise paths like "__libc_start_main (../foo/bar/libc-quux.c:129)"
-sed "s/__libc_\(.*\) (.*)$/__libc_\1 (...libc...)/" |
-
sed s/"^Open AF_UNIX socket [0-9]*: <unknown>/Open AF_UNIX socket .: <unknown>/" |
sed s/"^Open \(AF_UNIX socket\|file descriptor\) [0-9]*: \/dev\/null/Open \\1 .: \/dev\/null/" |
--- valgrind/memcheck/tests/filter_stderr #1.11:1.12
@@ -11,16 +11,3 @@
sed "s/mac_replace_strmem.c:[0-9]*/mac_replace_strmem.c:.../" |
-$dir/../../tests/filter_test_paths |
-
-# Anonymise paths like "(in /foo/bar/libc-baz.so)"
-sed "s/(in \/.*libc.*)$/(in \/...libc...)/" |
-
-# Anonymise paths like "(within /foo/bar/libc-baz.so)"
-sed "s/(within \/.*libc.*)$/(within \/...libc...)/" |
-
-# Anonymise paths like "xxx (../sysdeps/unix/sysv/linux/quux.c:129)"
-sed "s/(\.\.\/sysdeps\/unix\/sysv\/linux\/.*\.c:[0-9]*)$/(in \/...libc...)/" |
-
-# Anonymise paths like "__libc_start_main (../foo/bar/libc-quux.c:129)"
-sed "s/__libc_\(.*\) (.*)$/__libc_\1 (...libc...)/"
-
+$dir/../../tests/filter_test_paths
--- valgrind/none/tests/filter_stderr #1.7:1.8
@@ -6,6 +6,3 @@
# Anonymise addresses
-$dir/../../tests/filter_addresses |
-
-# Anonymise paths like "(in /foo/bar/libc-baz.so)"
-sed "s/(in \/.*libc.*)$/(in \/...libc...)/"
+$dir/../../tests/filter_addresses
--- valgrind/tests/filter_stderr_basic #1.19:1.20
@@ -4,4 +4,6 @@
# startup stuff and pid numbers.
+dir=`dirname $0`
+
# Remove ==pid== and --pid-- and ++pid++ and **pid** strings
sed "s/\(==\|--\|\+\+\|\*\*\)[0-9]\{1,5\}\1 //" |
@@ -29,8 +31,5 @@
# Reduce some libc incompatibility
-sed "s/ __getsockname / getsockname /" |
-sed "s/ __sigaction / sigaction /" |
-sed "s/ __GI___/ __/" |
-sed "s/ __\([a-z]*\)_nocancel / \1 /" |
+$dir/filter_libc |
# Remove line info out of order warnings
|
|
From: Tom H. <th...@cy...> - 2005-02-13 13:46:42
|
CVS commit by thughes:
Fix test results for new --command-line-only switch.
M +1 -0 cmdline1.stdout.exp 1.11
M +1 -0 cmdline2.stdout.exp 1.11
--- valgrind/none/tests/cmdline1.stdout.exp #1.10:1.11
@@ -16,4 +16,5 @@
--weird-hacks=hack1,hack2,... recognised hacks: lax-ioctls,ioctl-mmap [none]
--pointercheck=no|yes enforce client address space limits [yes]
+ --command-line-only=no|yes only use command line options [no]
user options for Valgrind tools that report errors:
--- valgrind/none/tests/cmdline2.stdout.exp #1.10:1.11
@@ -16,4 +16,5 @@
--weird-hacks=hack1,hack2,... recognised hacks: lax-ioctls,ioctl-mmap [none]
--pointercheck=no|yes enforce client address space limits [yes]
+ --command-line-only=no|yes only use command line options [no]
user options for Valgrind tools that report errors:
|
|
From: Tom H. <to...@co...> - 2005-02-13 13:37:55
|
In message <420...@ey...>
Eyal Lebedinsky <ey...@ey...> wrote:
> Probably unrelated, but the following is another matter I am looking at.
>
> I thought that VG uses something like double the memoey size (and a
> bit more) to keep the bitmaps, but the factor seen here is a few orders
> of magnitude above that. Here is what my server uses as it is brought
> up without any clients:
> VSZ RSS
> Without VG 53400 7692
> With VG 1603796 80388
I wouldn't pay too much attention to the virtual size when running
under valgrind as it deliberately keeps parts of the address space
mapped to stop the kernel placing things there. That space isn't
touched though so there is no real memory or swap being used.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2005-02-13 13:36:38
|
In message <420...@ey...>
Eyal Lebedinsky <ey...@ey...> wrote:
> Dirk Mueller wrote:
> > On Sunday 13 February 2005 09:14, Jeremy Fitzhardinge wrote:
> >
> >
> >>- res = VG_(do_syscall)(__NR_getrlimit, resource, (UWord)rlim);
> >>+ res = VG_(do_syscall)(__NR_ugetrlimit, resource, (UWord)rlim);
> >>+ if (res == -VKI_ENOSYS)
> >>+ res = VG_(do_syscall)(__NR_ugetrlimit, resource, (UWord)rlim);
>
> I applied the posted patch and my test still fails at the same point with
> the same error. was this change supposed to fix it?
I don't think it was supposed to fix your bug, no. That was the fix
the 2G stack bug that somebody raised on the bug tracker yesterday.
> VG_(get_memory_from_mmap): newSuperblock's request for 1048576 bytes failed.
> VG_(get_memory_from_mmap): 33599270 bytes already allocated.
>
> Sorry. You could try using a tool that uses less memory;
> eg. addrcheck instead of memcheck.
That usually just means your program is too big for valgrind
to cope with and it ran out of memory trying to load the debug
information or something.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Eyal L. <ey...@ey...> - 2005-02-13 13:28:17
|
Dirk Mueller wrote: > On Sunday 13 February 2005 09:14, Jeremy Fitzhardinge wrote: > > >>- res = VG_(do_syscall)(__NR_getrlimit, resource, (UWord)rlim); >>+ res = VG_(do_syscall)(__NR_ugetrlimit, resource, (UWord)rlim); >>+ if (res == -VKI_ENOSYS) >>+ res = VG_(do_syscall)(__NR_ugetrlimit, resource, (UWord)rlim); > > ^ > > this u is too much, no? > > > Dirk I applied the posted patch and my test still fails at the same point with the same error. was this change supposed to fix it? VG_(get_memory_from_mmap): newSuperblock's request for 1048576 bytes failed. VG_(get_memory_from_mmap): 33599270 bytes already allocated. Sorry. You could try using a tool that uses less memory; eg. addrcheck instead of memcheck. -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> attach .zip as .dat |
|
From: Tom H. <th...@cy...> - 2005-02-13 12:19:49
|
CVS commit by thughes:
Fall back to the getrlimit system call if the ugetrlimit system call
fails rather than just trying ugetrlimit again.
M +1 -1 vg_mylibc.c 1.111
--- valgrind/coregrind/vg_mylibc.c #1.110:1.111
@@ -1461,5 +1461,5 @@ Int VG_(getrlimit) (Int resource, struct
res = VG_(do_syscall)(__NR_ugetrlimit, resource, (UWord)rlim);
if (res == -VKI_ENOSYS)
- res = VG_(do_syscall)(__NR_ugetrlimit, resource, (UWord)rlim);
+ res = VG_(do_syscall)(__NR_getrlimit, resource, (UWord)rlim);
if(VG_(is_kerror)(res)) res = -1;
return res;
|
|
From: Tom H. <th...@cy...> - 2005-02-13 12:18:47
|
CVS commit by thughes:
Add a --command-line-only switch and make the test driver use it to
ensure that the user's .valgrindrc and/or the VALGRIND_OPTS environment
variable can't affect the tests.
M +11 -1 coregrind/vg_main.c 1.249
M +1 -1 tests/vg_regtest.in 1.29
--- valgrind/coregrind/vg_main.c #1.248:1.249
@@ -642,4 +642,6 @@ static void get_command_line( int argc,
} else {
+ Bool augment = True;
+
/* Count the arguments on the command line. */
vg_argv0 = argv;
@@ -652,4 +654,8 @@ static void get_command_line( int argc,
break;
}
+ if (VG_CLO_STREQ(argv[vg_argc0], "--command-line-only=yes"))
+ augment = False;
+ else if (VG_CLO_STREQ(argv[vg_argc0], "--command-line-only=no"))
+ augment = True;
}
cl_argv = &argv[vg_argc0];
@@ -658,4 +664,5 @@ static void get_command_line( int argc,
Note we don't do this if getting args from VALGRINDCLO, as
those extra args will already be present in VALGRINDCLO. */
+ if (augment)
augment_command_line(&vg_argc0, &vg_argv0);
}
@@ -1476,4 +1483,5 @@ void usage ( Bool debug_help )
" --weird-hacks=hack1,hack2,... recognised hacks: lax-ioctls,ioctl-mmap [none]\n"
" --pointercheck=no|yes enforce client address space limits [yes]\n"
+" --command-line-only=no|yes only use command line options [no]\n"
"\n"
" user options for Valgrind tools that report errors:\n"
@@ -1643,4 +1651,6 @@ static void process_cmd_line_options( UI
if (VG_CLO_STREQN(7, arg, "--exec="))
continue;
+ if (VG_CLO_STREQN(20, arg, "--command-line-only="))
+ continue;
if ( VG_CLO_STREQ(arg, "--"))
--- valgrind/tests/vg_regtest.in #1.28:1.29
@@ -283,5 +283,5 @@
# by an "args:" or "args.dev:" line, though).
my $tool=determine_tool();
- mysystem("VALGRINDLIB=$tests_dir/.in_place $valgrind --tool=$tool $vgopts $prog $args > $name.stdout.out 2> $name.stderr.out");
+ mysystem("VALGRINDLIB=$tests_dir/.in_place $valgrind --command-line-only=yes --tool=$tool $vgopts $prog $args > $name.stdout.out 2> $name.stderr.out");
if (defined $stdout_filter) {
|
|
From: Josef W. <Jos...@gm...> - 2005-02-13 12:16:46
|
On Saturday 12 February 2005 00:06, Jeremy Fitzhardinge wrote: > On Fri, 2005-02-11 at 15:13 -0600, Nicholas Nethercote wrote: > > On Fri, 11 Feb 2005, Julian Seward wrote: > > > It's dubious that the profiling can be made to work portably/reliably > > > now, and in any case since the JIT has been sawn off and made into a > > > library, profiling at least that part of the system is easy anyway > > > (by using a standalone test driver). So we may as well forget about > > > it, and nuke the associated code. > > > > It would be nice to have some kind of system-wide profiling, though. > > oprofile is getting very useful for this kind of thing. New versions Yes. I don't think there really is a need for the VG-internal profiling machanism. > can now take snapshots of the stack when they sample, so you get more > than a simple flat profile. If we can get it to generate some useful Yes. That is quite an interesting feature. But your code has to avoid -fomit-frame-pointer for this to work. Note that although OProfile itself can snapshot whole call chains, the current daemon breaks it up into (caller/callee) tuples. > profile data for generated code, it should cover almost all of our > profiling requirements... I am not really sure the relation of generated code to source is needed. But it would be a nifty thing: Writing the TC to an ELF file, and generate debug info for tools like OProfile to be able to get the source mapping after a VG run. As this would be a persistant TC, it could even be used to speed up further VG runs. Josef > > J > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Dirk M. <dm...@gm...> - 2005-02-13 11:30:57
|
On Sunday 13 February 2005 09:14, Jeremy Fitzhardinge wrote:
> - res = VG_(do_syscall)(__NR_getrlimit, resource, (UWord)rlim);
> + res = VG_(do_syscall)(__NR_ugetrlimit, resource, (UWord)rlim);
> + if (res == -VKI_ENOSYS)
> + res = VG_(do_syscall)(__NR_ugetrlimit, resource, (UWord)rlim);
^
this u is too much, no?
Dirk
|
|
From: Jeremy F. <je...@go...> - 2005-02-13 09:26:57
|
CVS commit by fitzhardinge:
Add some missing files to dist target.
M +2 -2 Makefile.am 1.63
--- valgrind/none/tests/Makefile.am #1.62:1.63
@@ -7,5 +7,5 @@
async-sigs.stderr.exp async-sigs.stdout.exp async-sigs.vgtest \
bitfield1.stderr.exp bitfield1.vgtest \
- blockfault.vgtest \
+ blockfault.vgtest blockfault.stderr.exp blockfault.stdout.exp \
closeall.stderr.exp closeall.vgtest \
cmdline1.stderr.exp cmdline1.stdout.exp cmdline1.vgtest \
@@ -29,5 +29,5 @@
fork.stderr.exp fork.stdout.exp fork.vgtest \
fucomip.stderr.exp fucomip.vgtest \
- getseg.stdout.exp getseg.vgtest \
+ getseg.stdout.exp getseg.stderr.exp getseg.vgtest \
gxx304.stderr.exp gxx304.vgtest \
map_unaligned.stderr.exp map_unaligned.vgtest \
|
|
From: Jeremy F. <je...@go...> - 2005-02-13 08:14:49
|
CVS commit by fitzhardinge:
Use the newer form of getrlimit which supports limits >2G, and therefore
represents RLIM_UNLIMITED.
BUGS:99195
M +3 -1 vg_mylibc.c 1.110
--- valgrind/coregrind/vg_mylibc.c #1.109:1.110
@@ -1459,5 +1459,7 @@ Int VG_(getrlimit) (Int resource, struct
Int res;
/* res = getrlimit( resource, rlim ); */
- res = VG_(do_syscall)(__NR_getrlimit, resource, (UWord)rlim);
+ res = VG_(do_syscall)(__NR_ugetrlimit, resource, (UWord)rlim);
+ if (res == -VKI_ENOSYS)
+ res = VG_(do_syscall)(__NR_ugetrlimit, resource, (UWord)rlim);
if(VG_(is_kerror)(res)) res = -1;
return res;
|
|
From: <js...@ac...> - 2005-02-13 04:00:44
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2005-02-13 03:50:00 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow rcl_assert: valgrind --num-callers=4 ./rcl_assert seg_override: valgrind --num-callers=4 ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind --num-callers=4 ./yield -- Finished tests in none/tests ---------------------------------------- == 196 tests, 11 stderr failures, 0 stdout failures ================= corecheck/tests/fdleak_fcntl (stderr) helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/scalar (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <to...@co...> - 2005-02-13 03:27:19
|
Nightly build on dunsmere ( Fedora Core 3 ) started at 2005-02-13 03:20:03 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow (cleanup operation failed: rm vgcore.pid*) pushpopseg: valgrind --num-callers=4 ./pushpopseg rcl_assert: valgrind --num-callers=4 ./rcl_assert seg_override: valgrind --num-callers=4 ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind --num-callers=4 ./yield -- Finished tests in none/tests ---------------------------------------- == 203 tests, 9 stderr failures, 0 stdout failures ================= helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) memcheck/tests/scalar (stderr) memcheck/tests/scalar_supp (stderr) memcheck/tests/vgtest_ume (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-02-13 03:23:49
|
Nightly build on audi ( Red Hat 9 ) started at 2005-02-13 03:15:03 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_socketpair (stderr) helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (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...> - 2005-02-13 03:17:20
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2005-02-13 03:10:03 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow (cleanup operation failed: rm vgcore.pid*) pushpopseg: valgrind --num-callers=4 ./pushpopseg rcl_assert: valgrind --num-callers=4 ./rcl_assert seg_override: valgrind --num-callers=4 ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind --num-callers=4 ./yield -- Finished tests in none/tests ---------------------------------------- == 201 tests, 9 stderr failures, 0 stdout failures ================= helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/scalar (stderr) memcheck/tests/threadederrno (stderr) make: *** [regtest] Error 1 |