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
(31) |
2
(27) |
|
3
(25) |
4
(21) |
5
(21) |
6
(21) |
7
(32) |
8
(23) |
9
(15) |
|
10
(12) |
11
(9) |
12
(10) |
13
(10) |
14
(9) |
15
(7) |
16
(20) |
|
17
(14) |
18
(71) |
19
(67) |
20
(50) |
21
(25) |
22
(15) |
23
(37) |
|
24
(25) |
25
(41) |
26
(34) |
27
(57) |
28
(20) |
29
(30) |
30
(13) |
|
31
(18) |
|
|
|
|
|
|
|
From: <sv...@va...> - 2005-07-18 23:56:47
|
Author: dirk Date: 2005-07-19 00:56:46 +0100 (Tue, 19 Jul 2005) New Revision: 4171 Log: allow to be build in a buildroot Modified: trunk/docs/Makefile.am Modified: trunk/docs/Makefile.am =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- trunk/docs/Makefile.am 2005-07-18 23:52:10 UTC (rev 4170) +++ trunk/docs/Makefile.am 2005-07-18 23:56:46 UTC (rev 4171) @@ -77,8 +77,8 @@ # the time. install-data-hook: if test -r html ; then \ - mkdir -p $(datadir)/doc/valgrind/; \ - cp -r html $(datadir)/doc/valgrind/; \ + mkdir -p $(DESTDIR)$(datadir)/doc/valgrind/; \ + cp -r html $(DESTDIR)$(datadir)/doc/valgrind/; \ fi =20 dist-hook: html-docs |
|
From: <sv...@va...> - 2005-07-18 23:52:58
|
Author: dirk Date: 2005-07-19 00:52:10 +0100 (Tue, 19 Jul 2005) New Revision: 4170 Log: remove the version script, doesn't work for executables Modified: trunk/coregrind/Makefile.am Modified: trunk/coregrind/Makefile.am =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- trunk/coregrind/Makefile.am 2005-07-18 23:23:03 UTC (rev 4169) +++ trunk/coregrind/Makefile.am 2005-07-18 23:52:10 UTC (rev 4170) @@ -81,7 +81,6 @@ vki_unistd-x86-linux.h =20 EXTRA_DIST =3D \ - valgrind.vs \ README_MODULES.txt =20 BUILT_SOURCES =3D stage2.lds @@ -149,13 +148,11 @@ ## Nb: older versions of automake don't seem to like having +=3D within = an ## if-then-else, so we have to use these variables for the common parts. st2_DEPS_common =3D \ - $(srcdir)/valgrind.vs \ $(stage2_extra) \ $(stage2_extra2) =20 st2_LDFLAGS_common =3D \ - -Wl,--export-dynamic -g \ - -Wl,-version-script $(srcdir)/valgrind.vs + -Wl,--export-dynamic -g =20 if USE_PIE stage2_DEPENDENCIES =3D $(st2_DEPS_common) |
|
From: Tom H. <th...@cy...> - 2005-07-18 23:24:09
|
SVN commit 436074 by thughes:
Fix crash when no environment is given to execve.
M +3 -4 vg_syscalls.c =20
--- trunk/valgrind/coregrind/vg_syscalls.c #436073:436074
@@ -1697,7 +1697,7 @@
PRE(sys_execve, Special)
{
Char *path; /* path to executable */
- Char **envp; /* environment */
+ Char **envp =3D NULL; /* environment */
=20
PRINT("sys_execve ( %p(%s), %p, %p )", arg1, arg1, arg2, arg3);
PRE_REG_READ3(vki_off_t, "execve",
@@ -1751,9 +1751,8 @@
// child doesn't get vg_inject.so, vgpreload.so, etc. This is
// done unconditionally, since if we are tracing the child,
// stage1/2 will set up the appropriate client environment.
- envp =3D VG_(env_clone)( (Char**)arg3 );
-
- if (envp !=3D NULL) {
+ if (arg3 !=3D NULL) {
+ envp =3D VG_(env_clone)( (Char**)arg3 );
VG_(env_remove_valgrind_env_stuff)( envp );=20
}
=20
|
|
From: <sv...@va...> - 2005-07-18 23:23:05
|
Author: tom
Date: 2005-07-19 00:23:03 +0100 (Tue, 19 Jul 2005)
New Revision: 4169
Log:
Fix crash when no environment is given to execve.
Modified:
trunk/coregrind/m_syswrap/syswrap-generic.c
Modified: trunk/coregrind/m_syswrap/syswrap-generic.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/m_syswrap/syswrap-generic.c 2005-07-18 23:18:10 UTC (=
rev 4168)
+++ trunk/coregrind/m_syswrap/syswrap-generic.c 2005-07-18 23:23:03 UTC (=
rev 4169)
@@ -2280,7 +2280,7 @@
PRE(sys_execve)
{
Char* path; /* path to executable */
- Char** envp;
+ Char** envp =3D NULL;
ThreadState* tst;
=20
PRINT("sys_execve ( %p(%s), %p, %p )", ARG1, ARG1, ARG2, ARG3);
@@ -2333,8 +2333,8 @@
// stage1/2 will set up the appropriate client environment.
// Nb: we make a copy of the environment before trying to mangle it
// as it might be in read-only memory (this was bug #101881).
- envp =3D VG_(env_clone)( (Char**)ARG3 );
- if (envp !=3D NULL) {
+ if (ARG3 !=3D NULL) {
+ envp =3D VG_(env_clone)( (Char**)ARG3 );
VG_(env_remove_valgrind_env_stuff)( envp );
}
=20
|
|
From: Tom H. <to...@co...> - 2005-07-18 23:19:21
|
In message <e51...@lo...>
Tom Hughes <to...@co...> wrote:
> In message <200...@ac...>
> Julian Seward <js...@ac...> wrote:
>
> > Does this reduce the amount of complaining the testsuite does on amd64?
>
> I don't think so, but it does mean I can now run our software without
> any complaints ;-) I'm running a regtest now to see where we're at...
The sigaltstack one I just committed does fix a test failure however.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: <sv...@va...> - 2005-07-18 23:18:13
|
Author: tom
Date: 2005-07-19 00:18:10 +0100 (Tue, 19 Jul 2005)
New Revision: 4168
Log:
Check members of the stack_t structure passed to sigaltstack
individually to avoid problems with padding on 64 bit platforms.
Modified:
trunk/coregrind/m_syswrap/syswrap-generic.c
Modified: trunk/coregrind/m_syswrap/syswrap-generic.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/m_syswrap/syswrap-generic.c 2005-07-18 22:45:55 UTC (=
rev 4167)
+++ trunk/coregrind/m_syswrap/syswrap-generic.c 2005-07-18 23:18:10 UTC (=
rev 4168)
@@ -5275,7 +5275,10 @@
PRE_REG_READ2(int, "sigaltstack",
const vki_stack_t *, ss, vki_stack_t *, oss);
if (ARG1 !=3D 0) {
- PRE_MEM_READ( "sigaltstack(ss)", ARG1, sizeof(vki_stack_t) );
+ const vki_stack_t *ss =3D (vki_stack_t *)ARG1;
+ PRE_MEM_READ( "sigaltstack(ss)", (Addr)&ss->ss_sp, sizeof(ss->ss_s=
p) );
+ PRE_MEM_READ( "sigaltstack(ss)", (Addr)&ss->ss_flags, sizeof(ss->s=
s_flags) );
+ PRE_MEM_READ( "sigaltstack(ss)", (Addr)&ss->ss_size, sizeof(ss->ss=
_size) );
}
if (ARG2 !=3D 0) {
PRE_MEM_WRITE( "sigaltstack(oss)", ARG2, sizeof(vki_stack_t) );
|
|
From: Tom H. <to...@co...> - 2005-07-18 23:13:05
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> > Check each field of the msghdr structure passed to sendmsg/recvmsg
> > individually to avoid complaints due to uninitialised padding bytes
> > on 64 bit platforms.
>
> Great stuff.
>
> Does this reduce the amount of complaining the testsuite does on amd64?
I don't think so, but it does mean I can now run our software without
any complaints ;-) I'm running a regtest now to see where we're at...
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2005-07-18 22:53:26
|
> Check each field of the msghdr structure passed to sendmsg/recvmsg > individually to avoid complaints due to uninitialised padding bytes > on 64 bit platforms. Great stuff. Does this reduce the amount of complaining the testsuite does on amd64? J |
|
From: <sv...@va...> - 2005-07-18 22:46:00
|
Author: tom
Date: 2005-07-18 23:45:55 +0100 (Mon, 18 Jul 2005)
New Revision: 4167
Log:
Check each member of the ifconf structure passed to SIOCGIFCONF
individually to avoid problems with padding bytes on 64 bit platforms.
Modified:
trunk/coregrind/m_syswrap/syswrap-generic.c
Modified: trunk/coregrind/m_syswrap/syswrap-generic.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/m_syswrap/syswrap-generic.c 2005-07-18 22:41:33 UTC (=
rev 4166)
+++ trunk/coregrind/m_syswrap/syswrap-generic.c 2005-07-18 22:45:55 UTC (=
rev 4167)
@@ -3257,7 +3257,12 @@
if (!VG_(is_kerror)(RES) && RES =3D=3D 0)
POST_MEM_WRITE(ARG3, sizeof(struct ifconf));
*/
- PRE_MEM_READ( "ioctl(SIOCGIFCONF)", ARG3, sizeof(struct vki_ifconf=
));
+ PRE_MEM_READ( "ioctl(SIOCGIFCONF)",
+ (Addr)&((struct vki_ifconf *)ARG3)->ifc_len,
+ sizeof(((struct vki_ifconf *)ARG3)->ifc_len));
+ PRE_MEM_READ( "ioctl(SIOCGIFCONF)",
+ (Addr)&((struct vki_ifconf *)ARG3)->vki_ifc_buf,
+ sizeof(((struct vki_ifconf *)ARG3)->vki_ifc_buf));
if ( ARG3 ) {
// TODO len must be readable and writable
// buf pointer only needs to be readable
|
|
From: <sv...@va...> - 2005-07-18 22:41:40
|
Author: tom
Date: 2005-07-18 23:41:33 +0100 (Mon, 18 Jul 2005)
New Revision: 4166
Log:
Check each field of the msghdr structure passed to sendmsg/recvmsg
individually to avoid complaints due to uninitialised padding bytes
on 64 bit platforms.
Also fixed sendmsg to check things which should be initialised (the
msghdr structure and the iov array) properly instead of doing a write
check for everything.
Modified:
trunk/coregrind/m_syswrap/syswrap-generic.c
Modified: trunk/coregrind/m_syswrap/syswrap-generic.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/m_syswrap/syswrap-generic.c 2005-07-18 17:53:07 UTC (=
rev 4165)
+++ trunk/coregrind/m_syswrap/syswrap-generic.c 2005-07-18 22:41:33 UTC (=
rev 4166)
@@ -586,45 +586,54 @@
}
=20
static=20
-void pre_mem_read_sendmsg ( ThreadId tid,
+void pre_mem_read_sendmsg ( ThreadId tid, Bool read,
Char *msg, Addr base, SizeT size )
{
Char *outmsg =3D strdupcat ( "socketcall.sendmsg", msg, VG_AR_CORE );
PRE_MEM_READ( outmsg, base, size );
-
VG_(arena_free) ( VG_AR_CORE, outmsg );
}
=20
static=20
-void pre_mem_write_recvmsg ( ThreadId tid,
+void pre_mem_write_recvmsg ( ThreadId tid, Bool read,
Char *msg, Addr base, SizeT size )
{
Char *outmsg =3D strdupcat ( "socketcall.recvmsg", msg, VG_AR_CORE );
- PRE_MEM_WRITE( outmsg, base, size );
+ if ( read )
+ PRE_MEM_READ( outmsg, base, size );
+ else
+ PRE_MEM_WRITE( outmsg, base, size );
VG_(arena_free) ( VG_AR_CORE, outmsg );
}
=20
static
-void post_mem_write_recvmsg ( ThreadId tid,
+void post_mem_write_recvmsg ( ThreadId tid, Bool read,
Char *fieldName, Addr base, SizeT size )
{
- POST_MEM_WRITE( base, size );
+ if ( !read )
+ POST_MEM_WRITE( base, size );
}
=20
static
void msghdr_foreachfield (=20
ThreadId tid,=20
struct vki_msghdr *msg,=20
- void (*foreach_func)( ThreadId, Char *, Addr, SizeT )=20
+ void (*foreach_func)( ThreadId, Bool, Char *, Addr, SizeT )=20
)
{
if ( !msg )
return;
=20
- foreach_func ( tid, "(msg)", (Addr)msg, sizeof( struct vki_msghdr ) )=
;
+ foreach_func ( tid, True, "(msg)", (Addr)&msg->msg_name, sizeof( msg-=
>msg_name ) );
+ foreach_func ( tid, True, "(msg)", (Addr)&msg->msg_namelen, sizeof( m=
sg->msg_namelen ) );
+ foreach_func ( tid, True, "(msg)", (Addr)&msg->msg_iov, sizeof( msg->=
msg_iov ) );
+ foreach_func ( tid, True, "(msg)", (Addr)&msg->msg_iovlen, sizeof( ms=
g->msg_iovlen ) );
+ foreach_func ( tid, True, "(msg)", (Addr)&msg->msg_control, sizeof( m=
sg->msg_control ) );
+ foreach_func ( tid, True, "(msg)", (Addr)&msg->msg_controllen, sizeof=
( msg->msg_controllen ) );
+ foreach_func ( tid, True, "(msg)", (Addr)&msg->msg_flags, sizeof( msg=
->msg_flags ) );
=20
if ( msg->msg_name )
- foreach_func ( tid,=20
+ foreach_func ( tid, False,
"(msg.msg_name)",=20
(Addr)msg->msg_name, msg->msg_namelen );
=20
@@ -632,18 +641,18 @@
struct vki_iovec *iov =3D msg->msg_iov;
UInt i;
=20
- foreach_func ( tid,=20
+ foreach_func ( tid, True,
"(msg.msg_iov)",=20
(Addr)iov, msg->msg_iovlen * sizeof( struct vki_iov=
ec ) );
=20
for ( i =3D 0; i < msg->msg_iovlen; ++i, ++iov )
- foreach_func ( tid,=20
+ foreach_func ( tid, False,
"(msg.msg_iov[i]",=20
(Addr)iov->iov_base, iov->iov_len );
}
=20
if ( msg->msg_control )
- foreach_func ( tid,=20
+ foreach_func ( tid, False,
"(msg.msg_control)",=20
(Addr)msg->msg_control, msg->msg_controllen );
}
|
|
From: Nicholas N. <nj...@cs...> - 2005-07-18 18:11:34
|
On Mon, 18 Jul 2005, Tom Hughes wrote: > I have a patch to default to using a vex in the top level valgrind > directory. It also fixes valgrind's makefiles to build vex if necessary. > > Combining that with a subversion external so that vex is checked out > with valgrind should provide a solution. Sounds good. >> - Addrcheck isn't working. Would be good if it did, but I can't see it >> happening any time soon. > > I think it should be fairly easy to re-enable - it was only disabled > to make things easier while getting memcheck going. Most of the hard > work is shared with the memcheck code anyway. I think it will be harder than you think. > Didn't Julian talk about dropping addrcheck though as it didn't seem > to have much point? My opinion was that this would be fine if/when we implement the compressed V-bit representation for Memcheck, but that currently Addrcheck is useful to have for people who have programs that use lots of memory. N |
|
From: <sv...@va...> - 2005-07-18 17:53:09
|
Author: tom Date: 2005-07-18 18:53:07 +0100 (Mon, 18 Jul 2005) New Revision: 4165 Log: Update svn:ignore lists. Modified: trunk/memcheck/tests/ trunk/none/tests/ trunk/none/tests/amd64/ Property changes on: trunk/memcheck/tests ___________________________________________________________________ Name: svn:ignore - addressable badaddrvalue badfree badjump badjump2 badloop badpoll badrw brk brk2 buflen_check clientperm clientstackperm custom_alloc .deps describe-block dir doublefree erringfds error_counts errs1 execve execve2 exitprog filter_leak_check_size filter_stderr fprw fwrite hello inits inline leak-0 leak-cycle leakotron leak-regroot leak-tree Makefile Makefile.in malloc1 malloc2 malloc3 manuel1 manuel2 manuel3 match-overrun memalign2 memalign_test memcmptest mempool metadata mismatches mmaptest nanoleak new_nothrow new_override null_socket overlap pointer-trace post-syscall realloc1 realloc2 realloc3 scalar scalar_exit_group scalar_fork scalar_supp scalar_vfork sigaltstack sigkill signal2 sigprocmask stack_changes *.stderr.diff* *.stderr.out *.stdout.diff *.stdout.out strchr str_tester supp1 supp2 suppfree threadederrno trivialleak vgtest_ume weirdioctl writev xml1 zeropage + addressable badaddrvalue badfree badjump badjump2 badloop badpoll badrw brk brk2 buflen_check clientperm clientstackperm custom_alloc .deps describe-block dir doublefree erringfds error_counts errs1 execve execve2 exitprog filter_leak_check_size filter_stderr fprw fwrite hello inits inline leak-0 leak-cycle leakotron leak-regroot leak-tree Makefile Makefile.in malloc1 malloc2 malloc3 manuel1 manuel2 manuel3 match-overrun memalign2 memalign_test memcmptest mempool metadata mismatches mmaptest nanoleak new_nothrow new_override null_socket overlap partiallydefinedeq pointer-trace post-syscall realloc1 realloc2 realloc3 scalar scalar_exit_group scalar_fork scalar_supp scalar_vfork sigaltstack sigkill signal2 sigprocmask stack_changes *.stderr.diff* *.stderr.out *.stdout.diff *.stdout.out strchr str_tester supp1 supp2 suppfree threadederrno trivialleak vgtest_ume weirdioctl with space writev xml1 zeropage Property changes on: trunk/none/tests ___________________________________________________________________ Name: svn:ignore - ansi args as_mmap as_shm async-sigs bitfield1 blockfault closeall coolo_sigaction coolo_strlen .deps discard exec-sigmask execve faultstatus fcntl_setown fdleak_cmsg fdleak_creat fdleak_dup fdleak_dup2 fdleak_fcntl fdleak_ipv4 fdleak_open fdleak_pipe fdleak_socketpair floored fork fucomip gxx304 insn_basic insn_basic.c insn_cmov insn_cmov.c insn_fpu insn_fpu.c insn_mmx insn_mmx.c insn_mmxext insn_mmxext.c insn_sse insn_sse2 insn_sse2.c insn_sse.c Makefile Makefile.in manythreads map_unaligned map_unmap mq mremap munmap_exe pending pluto pth_atfork1 pth_blockedsig pth_cancel1 pth_cancel2 pth_cvsimple pth_empty pth_exit pth_exit2 pth_mutexspeed pth_once pth_rwlock pth_semaphore1 pth_simple_mutex pth_simple_threads pth_specific pth_stackalign pth_yield rcrl readline1 resolv res_search rlimit_nofile selfrun sem semlimit sha1_test shortpush shorts sigstackgrowth smc1 *.so stackgrowth *.stderr.diff *.stderr.out *.stdout.diff *.stdout.out susphello syscall-restart1 syscall-restart2 system threadederrno threaded-fork thread-exits tls vgprintf yield + ansi args as_mmap as_shm async-sigs bitfield1 blockfault closeall coolo_sigaction coolo_strlen .deps discard exec-sigmask execve faultstatus fcntl_setown fdleak_cmsg fdleak_creat fdleak_dup fdleak_dup2 fdleak_fcntl fdleak_ipv4 fdleak_open fdleak_pipe fdleak_socketpair floored fork fucomip gxx304 insn_basic insn_basic.c insn_cmov insn_cmov.c insn_fpu insn_fpu.c insn_mmx insn_mmx.c insn_mmxext insn_mmxext.c insn_sse insn_sse2 insn_sse2.c insn_sse.c Makefile Makefile.in manythreads map_unaligned map_unmap mq mremap munmap_exe nestedfns pending pluto pth_atfork1 pth_blockedsig pth_cancel1 pth_cancel2 pth_cvsimple pth_empty pth_exit pth_exit2 pth_mutexspeed pth_once pth_rwlock pth_semaphore1 pth_simple_mutex pth_simple_threads pth_specific pth_stackalign pth_yield rcrl readline1 resolv res_search rlimit_nofile selfrun sem semlimit sha1_test shortpush shorts sigstackgrowth smc1 *.so stackgrowth *.stderr.diff *.stderr.out *.stdout.diff *.stdout.out susphello syscall-restart1 syscall-restart2 system threadederrno threaded-fork thread-exits tls vgprintf yield Property changes on: trunk/none/tests/amd64 ___________________________________________________________________ Name: svn:ignore - .deps insn_fpu insn_mmx insn_sse insn_sse2 Makefile Makefile.in + .deps insn_fpu insn_fpu.c insn_mmx insn_mmx.c insn_sse insn_sse.c insn_sse2 insn_sse2.c smc1 Makefile Makefile.in |
|
From: <sv...@va...> - 2005-07-18 17:50:43
|
Author: njn Date: 2005-07-18 18:50:38 +0100 (Mon, 18 Jul 2005) New Revision: 137 Log: Add Ada. Modified: trunk/info/about.html Modified: trunk/info/about.html =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- trunk/info/about.html 2005-07-13 13:45:26 UTC (rev 136) +++ trunk/info/about.html 2005-07-18 17:50:38 UTC (rev 137) @@ -74,7 +74,7 @@ can, for example, be used to debug and profile systems written in a mixture of languages. Valgrind has been used on programs written partly or entirely in C, C++, Java, Perl, Python, x86 -assembly code, Fortran, and many others.</li> +assembly code, Fortran, Ada, and many others.</li> =20 <li>Valgrind debugs and profiles your entire program. Unlike tools that require a recompilation step, Valgrind gives you total |
|
From: Duncan S. <bal...@fr...> - 2005-07-18 16:56:07
|
> > I ran the ACATS tests under valgrind. This is about 2400 tests > > comprising 150,000 lines of Ada code > > How useful is Valgrind with Ada programs? Are the bugs detected by > Memcheck (use of undefined values, accessing unaddressable memory, bad > frees, memory leaks) possible in Ada? Very useful, in my experience. Use of uninitialised values is certainly possible, and while they often get caught by the automatic range checking, they don't always get caught. This is the main thing valgrind catches in Ada programs in my experience [1]. Pointer arithmetic isn't used (or needed) much in Ada (for example it has a first class array structures, with automatic bounds checking, meaning that the array/pointer confusion in C and the associated problems simply aren't present), so the usual reason for ending up with a dud address is pointers pointing to freed memory, which certainly can and does happen (valgrind's saved my bacon a few times with this one). Finally, valgrind helps catch memory leaks. In my experience, heap allocation is needed a lot less in Ada than in, say, C or C++, but any decent sized program will have some heap allocation for use in linked lists etc, which means that memory problems and leaks are possible. By the way, the problems that valgrind finds in the ACATs tests are not (so far) problems with the tests themselves, but problems with the compiler. The tests push the front and back ends hard - and sometimes the compiler produces bad code which valgrind spots. All the best, Duncan. [1] The compiler can be told to automatically initialise all variables to extreme values that should be promptly spotted; nonetheless I've found valgrind to be more effective in finding uninitialised values. |
|
From: Tom H. <to...@co...> - 2005-07-18 16:38:00
|
In message <Pin...@ch...>
Nicholas Nethercote <nj...@cs...> wrote:
> It's a good point -- what does need to be done for 3.0? Here's my list:
>
> - Better Vex integration (ideally, users don't need to know about Vex at
> all when installing)
I have a patch to default to using a vex in the top level valgrind
directory. It also fixes valgrind's makefiles to build vex if necessary.
Combining that with a subversion external so that vex is checked out
with valgrind should provide a solution.
> - Addrcheck isn't working. Would be good if it did, but I can't see it
> happening any time soon.
I think it should be fairly easy to re-enable - it was only disabled
to make things easier while getting memcheck going. Most of the hard
work is shared with the memcheck code anyway.
Didn't Julian talk about dropping addrcheck though as it didn't seem
to have much point?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2005-07-18 16:35:49
|
In message <200...@gm...>
Dirk Mueller <dm...@gm...> wrote:
> On Monday 18 July 2005 17:22, Tom Hughes wrote:
>
> > I think that where this problem arises we should probably change
> > valgrind to check the structure members individually rather than
> > checking the whole structure so that any padding is ignored. Does
> > anybody have a problem with this before I start doing it?
>
> Performance loss? Perhaps it would be worth only doing the opposite, ignoring
> of padding bytes?
How? To start with there's no way to know where there are padding bytes
and even if there was the relevant memcheck entry points don't provide
for a list of regions not to check. Even if it did it would probably be
just as much of a slow down as just calling memcheck for each member.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Dirk M. <dm...@gm...> - 2005-07-18 16:28:18
|
On Monday 18 July 2005 17:22, Tom Hughes wrote: > I think that where this problem arises we should probably change > valgrind to check the structure members individually rather than > checking the whole structure so that any padding is ignored. Does > anybody have a problem with this before I start doing it? Performance loss? Perhaps it would be worth only doing the opposite, ignoring of padding bytes? Dirk |
|
From: Dirk M. <dm...@gm...> - 2005-07-18 16:07:52
|
On Monday 18 July 2005 16:44, Nicholas Nethercote wrote: > Dirk volunteered to do a 2.4.1 release, but there doesn't seem to be much > desire for it Well, just a couple of outstanding bug fixes. > and I think any effort would be better put towards the 3.0 > release, because 2.4.1 doesn't have that many improvements over 2.4.0. I > think most people will want 3.0, especially for AMD64 support. Remember that valgrind is used outside the repository as well, there are a few additional "tools" using the valgrind core machinery, e.g. kcachegrind. It will take a while until they're ported and stable with valgrind 3.0 - let alone valgrind 3.0 become stable. Therefore, I think maintaining 2.4.x is still a worthy goal, even if nothing interesting happens there. Thats okay. As long as a bugfix is as much work as applying a multiline trivial patch, thats fine. Also, I volunteered to do a 2.4.x release cycle because its important for distributors to pick up fixes. > I think this isn't working very well. The stable releases get old and > boring too quickly, and interesting stuff goes into the development > releases. We never had a 2.0.1 or 2.2.1 release, and I don't think we > need a 2.4.1. Remember the tool-interface. tool-interface changes should happen in the development branch. > How does that sound? I don't see the difference. BTW, gcc's release model is far more driven by people / vendors only wanting the bugfixes, but not the new features (which are likely to introduce regressions). Also, they have a testsuite to validate which fixes from trunk need backporting. How that matches with the idea of abandoning the stable branch? No idea. If anything, then the valgrind development model is more linux like than gcc like. how much changes do you see in linux 2.2.x these days? nothing besides urgent security fixes or major data loss bugs. Dirk |
|
From: Nicholas N. <nj...@cs...> - 2005-07-18 16:03:29
|
On Mon, 18 Jul 2005, Duncan Sands wrote: > I ran the ACATS tests under valgrind. This is about 2400 tests > comprising 150,000 lines of Ada code How useful is Valgrind with Ada programs? Are the bugs detected by Memcheck (use of undefined values, accessing unaddressable memory, bad frees, memory leaks) possible in Ada? N |
|
From: <sv...@va...> - 2005-07-18 15:52:37
|
Author: tom
Date: 2005-07-18 16:52:30 +0100 (Mon, 18 Jul 2005)
New Revision: 4164
Log:
If the client program is a PIE executable, avoid mapping it at
address zero. Instead do something like what the kernel does and
map it in the middle of the client address space.
Fix for bug #106283 based on patch from Sergey Vlasov.
Modified:
trunk/coregrind/m_ume.c
Modified: trunk/coregrind/m_ume.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/m_ume.c 2005-07-18 14:10:12 UTC (rev 4163)
+++ trunk/coregrind/m_ume.c 2005-07-18 15:52:30 UTC (rev 4164)
@@ -441,6 +441,12 @@
if (e =3D=3D NULL)
return ENOEXEC;
=20
+ /* The kernel maps position-independent executables at TASK_SIZE*2/3;
+ duplicate this behavior as close as we can. */
+ if (e->e.e_type =3D=3D ET_DYN && ebase =3D=3D 0) {
+ ebase =3D VG_PGROUNDDN(info->exe_base + (info->exe_end - info->exe=
_base) * 2 / 3);
+ }
+
info->phnum =3D e->e.e_phnum;
info->entry =3D e->e.e_entry + ebase;
info->phdr =3D 0;
@@ -513,7 +519,7 @@
}
=20
if (info->phdr =3D=3D 0)
- info->phdr =3D minaddr + e->e.e_phoff;
+ info->phdr =3D minaddr + ebase + e->e.e_phoff;
=20
if (info->exe_base !=3D info->exe_end) {
if (minaddr >=3D maxaddr ||
@@ -560,7 +566,7 @@
free(interp->p);
free(interp);
} else
- entry =3D (void *)e->e.e_entry;
+ entry =3D (void *)(ebase + e->e.e_entry);
=20
info->exe_base =3D minaddr + ebase;
info->exe_end =3D maxaddr + ebase;
|
|
From: Nicholas N. <nj...@cs...> - 2005-07-18 15:50:38
|
On Mon, 18 Jul 2005, Tom Hughes wrote: >> Julian is thinking about doing a 3.0 release soon, ie. doing a release >> candidate in the next week or so. > > I think there are few things that we need to think about before a > release - there is the question of whether or not to integrate vex > which I emailed Julian about a week or so back and also issues about > packaging and support for 32 bit binaries on 64 bit systems which > Robert raised on the list recently. > > I've got one other issue on 64 bit systems that I need to look at > and we should probably have a look at what bugs are outstanding as > we've been concentrating more on the question of getting 3.0 more > or less working of late. It's a good point -- what does need to be done for 3.0? Here's my list: - Better Vex integration (ideally, users don't need to know about Vex at all when installing) - SegInfos currently are not deallocated properly, this should be fixed. - Addrcheck isn't working. Would be good if it did, but I can't see it happening any time soon. What other things should be added to this list? N |
|
From: Nicholas N. <nj...@cs...> - 2005-07-18 15:30:31
|
On Mon, 18 Jul 2005, Tom Hughes wrote: > There are some system calls which take pointers to structures as > arguments where the structures have padding on 64 bit systems that > they didn't have on 32 bit systems due to pointers within the > structures increasing in size. > > Currently valgrind sometimes reports errors from these system calls > if the client program has simply filled in all the fields in the > structure rather than using memset to initialise it before filling > in the fields. > > Typical examples of this are sendmsg and recvmsg. I've also seen it > with some of the SIOGxxx ioctls. > > I think that where this problem arises we should probably change > valgrind to check the structure members individually rather than > checking the whole structure so that any padding is ignored. Does > anybody have a problem with this before I start doing it? Sounds like a necessary evil... N |
|
From: Tom H. <to...@co...> - 2005-07-18 15:23:07
|
There are some system calls which take pointers to structures as arguments where the structures have padding on 64 bit systems that they didn't have on 32 bit systems due to pointers within the structures increasing in size. Currently valgrind sometimes reports errors from these system calls if the client program has simply filled in all the fields in the structure rather than using memset to initialise it before filling in the fields. Typical examples of this are sendmsg and recvmsg. I've also seen it with some of the SIOGxxx ioctls. I think that where this problem arises we should probably change valgrind to check the structure members individually rather than checking the whole structure so that any padding is ignored. Does anybody have a problem with this before I start doing it? Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: Tom H. <to...@co...> - 2005-07-18 15:19:23
|
In message <Pin...@ch...>
Nicholas Nethercote <nj...@cs...> wrote:
> On Mon, 18 Jul 2005, Tom Hughes wrote:
>
>> SVN commit 435880 by thughes:
>>
>> Backport fixes for bugs #103509, #106293, #104797, #101881 from
>> the valgrind 3.0 tree.
>
> Julian is thinking about doing a 3.0 release soon, ie. doing a release
> candidate in the next week or so.
I think there are few things that we need to think about before a
release - there is the question of whether or not to integrate vex
which I emailed Julian about a week or so back and also issues about
packaging and support for 32 bit binaries on 64 bit systems which
Robert raised on the list recently.
I've got one other issue on 64 bit systems that I need to look at
and we should probably have a look at what bugs are outstanding as
we've been concentrating more on the question of getting 3.0 more
or less working of late.
> I suggest we abandon the even/odd numbering scheme, and partially
> abandon the stable/development split. I think we'd increase the
> minor-minor version (eg. 3.0.0 to 3.0.1) for releases that have
> not-too-big changes (ie. allow more than just bug fixes in them), and
> increase the minor version (eg. 3.0.1 to 3.1.0) for bigger changes.
> What constitutes a bigger change? I guess things like Jeremy's FV
> memory reworking or libpthread-removal. Things where it's conceivable
> that we might want to undo a big change if it doesn't work out. In
> those cases we could maintain a temporary stable/development split
> (eg. 3.0.1/3.1.0) until the new feature has had time to settle in.
This sounds like a reasonable idea.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Nicholas N. <nj...@cs...> - 2005-07-18 14:44:32
|
On Mon, 18 Jul 2005, Tom Hughes wrote: > SVN commit 435880 by thughes: > > Backport fixes for bugs #103509, #106293, #104797, #101881 from > the valgrind 3.0 tree. Julian is thinking about doing a 3.0 release soon, ie. doing a release candidate in the next week or so. Dirk volunteered to do a 2.4.1 release, but there doesn't seem to be much desire for it, and I think any effort would be better put towards the 3.0 release, because 2.4.1 doesn't have that many improvements over 2.4.0. I think most people will want 3.0, especially for AMD64 support. ---- On a related note, I'd like to propose that we change the way we number and do releases. Previously we've followed the old Linux kernel scheme where even-numbered releases (2.2.X, 2.4.X, etc) are "stable", and odd-numbered release (2.1.X, 2.3.X, etc) are "development" releases. Only bug-fixes go into stable lines. I think this isn't working very well. The stable releases get old and boring too quickly, and interesting stuff goes into the development releases. We never had a 2.0.1 or 2.2.1 release, and I don't think we need a 2.4.1. We invariably recommend the development releases over the stable releases, saying "although it is a development release, it's much better than the last stable release". I suggest we abandon the even/odd numbering scheme, and partially abandon the stable/development split. I think we'd increase the minor-minor version (eg. 3.0.0 to 3.0.1) for releases that have not-too-big changes (ie. allow more than just bug fixes in them), and increase the minor version (eg. 3.0.1 to 3.1.0) for bigger changes. What constitutes a bigger change? I guess things like Jeremy's FV memory reworking or libpthread-removal. Things where it's conceivable that we might want to undo a big change if it doesn't work out. In those cases we could maintain a temporary stable/development split (eg. 3.0.1/3.1.0) until the new feature has had time to settle in. Overall this would be more like the GCC release model, although not as formal and we wouldn't maintain older branches nearly as long (eg. they're still doing releases like 3.3.6 even though 3.4.X and 4.0.X have been released). How does that sound? N |