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
(9) |
2
(13) |
3
(3) |
4
(3) |
5
(4) |
|
6
(2) |
7
(4) |
8
(3) |
9
(2) |
10
|
11
|
12
(6) |
|
13
(6) |
14
(1) |
15
(2) |
16
(2) |
17
(2) |
18
|
19
|
|
20
|
21
|
22
(1) |
23
|
24
(2) |
25
(5) |
26
|
|
27
(1) |
28
(8) |
29
(3) |
30
|
|
|
|
|
From: Nicholas N. <nj...@ca...> - 2003-04-15 13:07:43
|
Hi, I just made a big commit. Valgrind now longer overrides malloc() et al by default, it's up to individual skins to override those functions if they need to know about heap memory. This makes the core/skin split much cleaner. The core/skin interface has changed a bit as a result. I have (of course) updated all the distributed skins, but external skins (eg. Josef's calltree) will need to be updated. The changes aren't very big; sorry about this, but it was necessary. Apologies to those maintaining patches against the head, I hope you can update and regenerate them without too much trouble. N |
|
From: Nicholas N. <nj...@ca...> - 2003-04-14 17:20:18
|
On 13 Apr 2003, Nathan Neulinger wrote: > Something I've seen that is a little odd is vg saying unitialized error > and pointing at the last line of a function - on the brace. What data > could it be referring to in that case? Sometimes debug info is imprecise. If you really want to know what's going on, use "objdump -S" to see what instruction is at the error-causing address. N |
|
From: Madhu M. K. <mm...@ya...> - 2003-04-13 19:43:43
|
Nicholas Nethercote wrote: >> I have a feeling that some of the cases are due to propagation >> (copying/passing undefined vals up and down through various subroutine >> calls), but there are a ton of places that it looks like the code >> assumes things start as zero. > >Assuming malloc'd memory is zeroed is an easy mistake to make, since many >malloc() implementations do zero even though this isn't required. (Not >sure about glibc, though.) Could the confusion be thanks to the fact that globals/statics are set to 0; sometime in the history of the development, these variables moved into the fuction? ... Just a thought. Cheerio, M p.s. Julian, can we please set the Reply-To to the list email id by default? If one is not careful, the possibility of spamming you or Nicholas is non trivial.... Madhu M Kurup /* Nemo Me Impune Lacessit */ mmk at yahoo-inc dt com |
|
From: Nathan N. <nn...@um...> - 2003-04-13 19:27:20
|
On Sun, 2003-04-13 at 04:37, Nicholas Nethercote wrote: > > I have a feeling that some of the cases are due to propagation > > (copying/passing undefined vals up and down through various subroutine > > calls), but there are a ton of places that it looks like the code > > assumes things start as zero. > > Assuming malloc'd memory is zeroed is an easy mistake to make, since many > malloc() implementations do zero even though this isn't required. (Not > sure about glibc, though.) Actually, I think most are for automatic vars in functions... but I'm not certain. Something I've seen that is a little odd is vg saying unitialized error and pointing at the last line of a function - on the brace. What data could it be referring to in that case? -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nn...@um... University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 |
|
From: Nathan N. <nn...@um...> - 2003-04-13 19:22:28
|
> You have probably already worked this out, but... the essential case
> corresponds to the 'post_mem_write' event. The non-essential cases
> correspond to the 'pre_mem_{read,write}' events. If any of the AFS system
> sub-calls 'allocate' or change the permissions of memory, eg. like mmap()
> or brk() or mprotect() do, then a new event (corresponding to eg.
> new_mem_mmap()) might be needed. Tell me if so, I can help you work out
> the details.
Not as far as I know... they should almost all be done with data getting
passed into the call. I figure that most of the afs syscall issues can
be resolved by marking that the syscall wrote to the memory. That should
hopefully get all of the propagation issues fixed relative the system
calls. Of course, that leaves thousands of other places.
I must say that in the short time I've been fiddling with valgrind (a
day), I really really resent the fact that I didn't have this tool a few
years ago. :) Makes dmalloc and efence look like toys. (Excellent tools,
but valgrind kicks butt.)
-- Nathan
------------------------------------------------------------
Nathan Neulinger EMail: nn...@um...
University of Missouri - Rolla Phone: (573) 341-4841
Computing Services Fax: (573) 341-4216
|
|
From: Eyal L. <ey...@ey...> - 2003-04-13 14:15:56
|
I submitted the patch during 1.9.4 but I do not see it in 1.9.5. I need it and have to apply it again. So here it is again for 1.9.5, let me know if there is any problem with it or how I should I submit it properly. This patch enables timestamping error reports to allow correlating them to other activity on the machine. It adds the option --time-stamp and a related --time-zone option to specify your time offset relative to UTC. -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> |
|
From: Nicholas N. <nj...@ca...> - 2003-04-13 09:37:37
|
On 12 Apr 2003, Nathan Neulinger wrote: > Thanks, found that in the docs and c-faq after reading closer. Looking > around and testing against the afs code, it is very clear that this code > is in need of some major grinding. A small number of the instances are > bogus, due to the afs syscall not being processed yet. But there are > many hundreds of other places where it is not so easily dismissed. > > I have a feeling that some of the cases are due to propagation > (copying/passing undefined vals up and down through various subroutine > calls), but there are a ton of places that it looks like the code > assumes things start as zero. Assuming malloc'd memory is zeroed is an easy mistake to make, since many malloc() implementations do zero even though this isn't required. (Not sure about glibc, though.) > Question related to adding the afs_syscall support (which so far seems > straightforward). I have a structure definition and about 30-40 AFSCALL_ > and AFSPIOCTL_ defines (instead of coding them in numerically). Where > would it be best to put these? It didn't look like vg_include.h was > appropriate. > > Right now, I just have them stuck in vg_syscalls.c somewhere. If the support is only needed within vg_syscalls.c, then that is probably the best place -- might as well keep the defitions local. N |
|
From: Nicholas N. <nj...@ca...> - 2003-04-13 09:32:50
|
On Sat, 12 Apr 2003, Julian Seward wrote:
> Well, there's a distinction to be made between _want_ and _need_.
> At the bare minimum, you _must_ say how the state of memory is
> altered after the syscall, otherwise memory checking won't work
> correctly. You need to tell V about changes in memory permissions
> after the call.
>
> Optionally -- and this is done with almost all syscalls -- you can
> add some stuff which checks addressibility & definedness of memory
> passed to the system call. This is nice to have -- it enables
> V to tell people to see when they are passing garbage to syscalls
> -- but it isn't per se essential.
You have probably already worked this out, but... the essential case
corresponds to the 'post_mem_write' event. The non-essential cases
correspond to the 'pre_mem_{read,write}' events. If any of the AFS system
sub-calls 'allocate' or change the permissions of memory, eg. like mmap()
or brk() or mprotect() do, then a new event (corresponding to eg.
new_mem_mmap()) might be needed. Tell me if so, I can help you work out
the details.
Julian's classification of essential vs. non-essential was based around
the Memcheck skin, but since Valgrind can be used for writing other
program supervision tools by writing new skins; the 'non-essential' events
really should be included, as they might be essential for some other skin.
N
|
|
From: Nathan N. <nn...@um...> - 2003-04-12 22:50:11
|
Thanks, found that in the docs and c-faq after reading closer. Looking
around and testing against the afs code, it is very clear that this code
is in need of some major grinding. A small number of the instances are
bogus, due to the afs syscall not being processed yet. But there are
many hundreds of other places where it is not so easily dismissed.
I have a feeling that some of the cases are due to propagation
(copying/passing undefined vals up and down through various subroutine
calls), but there are a ton of places that it looks like the code
assumes things start as zero.
Question related to adding the afs_syscall support (which so far seems
straightforward). I have a structure definition and about 30-40 AFSCALL_
and AFSPIOCTL_ defines (instead of coding them in numerically). Where
would it be best to put these? It didn't look like vg_include.h was
appropriate.
Right now, I just have them stuck in vg_syscalls.c somewhere.
-- Nathan
On Sat, 2003-04-12 at 16:52, Julian Seward wrote:
> On Saturday 12 April 2003 4:32 pm, Nathan Neulinger wrote:
> > Ok. I'll see what I can come up with and will send you a diff.
> >
> > Right now, I'm just trying to get familiar enough with vg to understand
> > to start looking at some of the code and understand why I'm getting
> > unitialized errors in places that sure look like it's initialized...
> > Going to experiment some more to make sure it's not my misunderstanding
> > something.
> >
> > Just to make certain of one thing - if you have:
> >
> > int somefunc(void)
> > {
> > char x[20];
> >
> > if ( x[0] ... )
> > {
> >
> > }
> > }
> >
> > That shouldn't trigger an unitialized access should it?
>
> Absolutely it should; x[0] contains whatever garbage was on the
> stack ; it isn't magically initalised.
>
> J
>
> >
> > -- Nathan
> >
> > On Sat, 2003-04-12 at 11:25, Julian Seward wrote:
> > > On Saturday 12 April 2003 2:47 pm, Nathan Neulinger wrote:
> > > > Looking to try valgrinding the openafs user space tools and file server
> > > > code. At a minimum, I needed to add
> > > >
> > > > case __NR_afs_syscall: /* syscall 137 */
> > > > MAYBE_PRINTF("afs ( )\n");
> > > > KERNEL_DO_SYSCALL(tid,res);
> > > > break;
> > > >
> > > >
> > > > What I'm wondering is - how much analysis code do y'all want in
> > > > there... I can flesh out alot of the behavior of that system call, but
> > > > are you interested in having it in there?
> > >
> > > Well, there's a distinction to be made between _want_ and _need_.
> > > At the bare minimum, you _must_ say how the state of memory is
> > > altered after the syscall, otherwise memory checking won't work
> > > correctly. You need to tell V about changes in memory permissions
> > > after the call.
> > >
> > > Optionally -- and this is done with almost all syscalls -- you can
> > > add some stuff which checks addressibility & definedness of memory
> > > passed to the system call. This is nice to have -- it enables
> > > V to tell people to see when they are passing garbage to syscalls
> > > -- but it isn't per se essential.
> > >
> > > I'd rather have as much detail as possible, since that makes it
> > > most useful to people debugging code with afs syscalls in, including
> > > you :)
> > >
> > > J
--
------------------------------------------------------------
Nathan Neulinger EMail: nn...@um...
University of Missouri - Rolla Phone: (573) 341-4841
Computing Services Fax: (573) 341-4216
|
|
From: Julian S. <js...@ac...> - 2003-04-12 21:53:01
|
On Saturday 12 April 2003 4:32 pm, Nathan Neulinger wrote:
> Ok. I'll see what I can come up with and will send you a diff.
>
> Right now, I'm just trying to get familiar enough with vg to understand
> to start looking at some of the code and understand why I'm getting
> unitialized errors in places that sure look like it's initialized...
> Going to experiment some more to make sure it's not my misunderstanding
> something.
>
> Just to make certain of one thing - if you have:
>
> int somefunc(void)
> {
> char x[20];
>
> if ( x[0] ... )
> {
>
> }
> }
>
> That shouldn't trigger an unitialized access should it?
Absolutely it should; x[0] contains whatever garbage was on the
stack ; it isn't magically initalised.
J
>
> -- Nathan
>
> On Sat, 2003-04-12 at 11:25, Julian Seward wrote:
> > On Saturday 12 April 2003 2:47 pm, Nathan Neulinger wrote:
> > > Looking to try valgrinding the openafs user space tools and file server
> > > code. At a minimum, I needed to add
> > >
> > > case __NR_afs_syscall: /* syscall 137 */
> > > MAYBE_PRINTF("afs ( )\n");
> > > KERNEL_DO_SYSCALL(tid,res);
> > > break;
> > >
> > >
> > > What I'm wondering is - how much analysis code do y'all want in
> > > there... I can flesh out alot of the behavior of that system call, but
> > > are you interested in having it in there?
> >
> > Well, there's a distinction to be made between _want_ and _need_.
> > At the bare minimum, you _must_ say how the state of memory is
> > altered after the syscall, otherwise memory checking won't work
> > correctly. You need to tell V about changes in memory permissions
> > after the call.
> >
> > Optionally -- and this is done with almost all syscalls -- you can
> > add some stuff which checks addressibility & definedness of memory
> > passed to the system call. This is nice to have -- it enables
> > V to tell people to see when they are passing garbage to syscalls
> > -- but it isn't per se essential.
> >
> > I'd rather have as much detail as possible, since that makes it
> > most useful to people debugging code with afs syscalls in, including
> > you :)
> >
> > J
|
|
From: Nathan N. <nn...@um...> - 2003-04-12 16:32:21
|
Ok. I'll see what I can come up with and will send you a diff.
Right now, I'm just trying to get familiar enough with vg to understand
to start looking at some of the code and understand why I'm getting
unitialized errors in places that sure look like it's initialized...
Going to experiment some more to make sure it's not my misunderstanding
something.
Just to make certain of one thing - if you have:
int somefunc(void)
{
char x[20];
if ( x[0] ... )
{
}
}
That shouldn't trigger an unitialized access should it?
-- Nathan
On Sat, 2003-04-12 at 11:25, Julian Seward wrote:
> On Saturday 12 April 2003 2:47 pm, Nathan Neulinger wrote:
> > Looking to try valgrinding the openafs user space tools and file server
> > code. At a minimum, I needed to add
> >
> > case __NR_afs_syscall: /* syscall 137 */
> > MAYBE_PRINTF("afs ( )\n");
> > KERNEL_DO_SYSCALL(tid,res);
> > break;
> >
> >
> > What I'm wondering is - how much analysis code do y'all want in there...
> > I can flesh out alot of the behavior of that system call, but are you
> > interested in having it in there?
>
> Well, there's a distinction to be made between _want_ and _need_.
> At the bare minimum, you _must_ say how the state of memory is
> altered after the syscall, otherwise memory checking won't work
> correctly. You need to tell V about changes in memory permissions
> after the call.
>
> Optionally -- and this is done with almost all syscalls -- you can
> add some stuff which checks addressibility & definedness of memory
> passed to the system call. This is nice to have -- it enables
> V to tell people to see when they are passing garbage to syscalls
> -- but it isn't per se essential.
>
> I'd rather have as much detail as possible, since that makes it
> most useful to people debugging code with afs syscalls in, including
> you :)
>
> J
--
------------------------------------------------------------
Nathan Neulinger EMail: nn...@um...
University of Missouri - Rolla Phone: (573) 341-4841
Computing Services Fax: (573) 341-4216
|
|
From: Julian S. <js...@ac...> - 2003-04-12 16:25:47
|
On Saturday 12 April 2003 2:47 pm, Nathan Neulinger wrote:
> Looking to try valgrinding the openafs user space tools and file server
> code. At a minimum, I needed to add
>
> case __NR_afs_syscall: /* syscall 137 */
> MAYBE_PRINTF("afs ( )\n");
> KERNEL_DO_SYSCALL(tid,res);
> break;
>
>
> What I'm wondering is - how much analysis code do y'all want in there...
> I can flesh out alot of the behavior of that system call, but are you
> interested in having it in there?
Well, there's a distinction to be made between _want_ and _need_.
At the bare minimum, you _must_ say how the state of memory is
altered after the syscall, otherwise memory checking won't work
correctly. You need to tell V about changes in memory permissions
after the call.
Optionally -- and this is done with almost all syscalls -- you can
add some stuff which checks addressibility & definedness of memory
passed to the system call. This is nice to have -- it enables
V to tell people to see when they are passing garbage to syscalls
-- but it isn't per se essential.
I'd rather have as much detail as possible, since that makes it
most useful to people debugging code with afs syscalls in, including
you :)
J
|
|
From: Nathan N. <nn...@um...> - 2003-04-12 14:48:07
|
Looking to try valgrinding the openafs user space tools and file server
code. At a minimum, I needed to add
case __NR_afs_syscall: /* syscall 137 */
MAYBE_PRINTF("afs ( )\n");
KERNEL_DO_SYSCALL(tid,res);
break;
What I'm wondering is - how much analysis code do y'all want in there...
I can flesh out alot of the behavior of that system call, but are you
interested in having it in there?
-- Nathan
------------------------------------------------------------
Nathan Neulinger EMail: nn...@um...
University of Missouri - Rolla Phone: (573) 341-4841
Computing Services Fax: (573) 341-4216
|
|
From: Julian S. <js...@ac...> - 2003-04-12 09:12:58
|
Adam I've been thinking a bit about your Wine patches, and even looked at www.winehq.com to see if anyone mentioned anything more about running Wine on V. It would be nice to see a whole bunch of bug fixes to Wine committed as a result. I think it will be a significant period of time before your changes can get integrated into the head. One reason is that there are a various plans in discussion regarding other changes to the head, (SSE, NPTL, elf loaders, more modularity) which will soak up our time for a while. Also, JeremyF is away for a month, and he seems to have the best understanding of how your changes interact with JeffD's/his changes for UML and how to reconcile the two. Just in case it isn't clear, I think it's excellent that you've made V work with Wine. It's unfortunate that the stuff you've had to change is the most awkward part of V -- the "environment simulation" -- signals, threads, etc -- which is why it's hard to figure out the best way to merge it. So, my suggestion is that for the time being you make your patch available as a patch against the current stable version, 1.9.5. (The 1.0.X series is now officially dead). Although not ideal, it makes your stuff available right now to Wine hackers. I hope that 1.9.X is not going to change very much at all, since it is a stable branch, and so you will have little or zero hassle tracking the 1.9.X branch. If you want, I can put suitable links on the valgrind web page (http://developer.kde.org/~sewardj) to your patch distributing page(s), saying "You can debug Wine with a patched valgrind; see here (link) for a patch against 1.9.5". (Somewhat off-topic, but ...) Is there a list anywhere of the bugs you found in Wine? I'd be interested to see ... J |
|
From: Nicholas N. <nj...@ca...> - 2003-04-09 13:08:11
|
On Wed, 9 Apr 2003, Nicholas Nethercote wrote:
> vgskin_addrcheck_so_SOURCES = ac_main.c
> vgskin_addrcheck_so_LDFLAGS = -shared
> vgskin_addrcheck_so_LDADD = \
> mac_leakcheck.c \
> mac_needs.c
[sigh] that should read
vgskin_addrcheck_so_SOURCES = ac_main.c
vgskin_addrcheck_so_LDFLAGS = -shared
vgskin_addrcheck_so_LDADD = \
../memcheck/mac_leakcheck.o \
../memcheck/mac_needs.o
N
|
|
From: Nicholas N. <nj...@ca...> - 2003-04-09 12:48:23
|
Hi,
I have a question about automake.
The Memcheck and Addrcheck skins share some code, in two files.
These shared files are stored in the memcheck/ directory. Previously, I
was having Addrcheck's ac_main.c #include the .c files directly. But this
is kind of nasty.
So I want to change it so it simply links them in when vgskin_addrcheck.so
is being made. I've done this using an "LDADD" variable in
addrcheck/Makefile.am, like so:
vgskin_addrcheck_so_SOURCES = ac_main.c
vgskin_addrcheck_so_LDFLAGS = -shared
vgskin_addrcheck_so_LDADD = \
mac_leakcheck.c \
mac_needs.c
This works, on one condition -- that mac_leakcheck.o and mac_needs.o have
been built beforehand. I can force this by changing the order of the
SUBDIRS variable in to the top-level Makefile.am so that Memcheck is built
ahead of Addrcheck, but this seems a bit ad hoc. I want a nice way to
specify in addrcheck/Makefile.am "please compile these files first".
I tried changing the SUBDIRS variable in addrcheck/Makefile.am to this:
SUBDIRS = ../memcheck . docs tests
but automake doesn't like the "..".
Does anyone know if there's a way with automake to force the
pre-compilation of files in other directories that aren't subdirectories
of the current one?
Thanks.
N
|
|
From: Adam G. <ar...@cy...> - 2003-04-08 10:56:15
|
At 03:00 08/04/03 -0700, Jeremy Fitzhardinge wrote: >Quoting Julian Seward <js...@ac...>: > >> >> I've spent the afternoon messing with R H 9. Graydon and Jeff have >> done a great job telling me useful stuff for getting V to work on >> RH9, and thanks to them for that. >> >> So it sort-of works. Unfortunately OpenOffice hangs, due to an >> accept() >> call which isn't correctly routed to V's only-this-thread-blocks >> implementation thereof, and so the whole app hangs. Sigh. I think it >> might be due to ld.so in 9 ignoring -z initfirst. > >At least one possible problem is that if two things have initfirst - well, they >can't both be first. > >> It's all a swamp, and V is getting more and more cluttered with stuff >> to work around this kind of problem. JeremyF's vg_intercept.c thing >> is the latest addition. > >And it is well ugh-worthy. > >> 1. We can't really simulate the native posix threading libraries; > >What do you mean by "simulate"? Do you mean we can emulate the presence of the >library, but we can't run a simulation of the actual library? > >What we could do is move Valgrind's thread simulation an abstraction level down, >and intercept the clone system call, and then run the "real" thread library on >that. Unfortunately that loses the higher-level insight Valgrind gets into the >threading behaviour of the target program. clone() implementation patch available on request... ;-) this is exactly what I did for valgrind's WINE support. there are several problems with implementing clone() using 'green' threads - the biggest one is that external processes cannot send signals to the new threads (it's causing major headaches trying to get patches into WINE to cope with this). if you want to REALLY clone a new thread, then you'll have to add all sorts of locking to valgrind to cope with it - I had a look at this but it appears to be a big job. currently valgrind itself is pretty much single threaded - with real cloned threads that won't be the case. Seeya, Adam -- Real Programmers don't comment their code. If it was hard to write, it should be hard to read, and even harder to modify. These are all my own opinions. |
|
From: Nicholas N. <nj...@ca...> - 2003-04-08 10:34:02
|
Hi, I just added a Makefile target for running the regression tests. Use "make regtest" to run them now. This is slightly easier than the old '$PREFIX/bin/vg_regtest --all'. If anyone ever wants to add some regression tests, feel free. If you are unsure about how the script works, you can send me the test program along with the expected normal output and Valgrind output and I'll add it. N |
|
From: Jeremy F. <je...@go...> - 2003-04-08 10:00:46
|
Quoting Julian Seward <js...@ac...>: > > I've spent the afternoon messing with R H 9. Graydon and Jeff have > done a great job telling me useful stuff for getting V to work on > RH9, and thanks to them for that. > > So it sort-of works. Unfortunately OpenOffice hangs, due to an > accept() > call which isn't correctly routed to V's only-this-thread-blocks > implementation thereof, and so the whole app hangs. Sigh. I think it > might be due to ld.so in 9 ignoring -z initfirst. At least one possible problem is that if two things have initfirst - well, they can't both be first. > It's all a swamp, and V is getting more and more cluttered with stuff > to work around this kind of problem. JeremyF's vg_intercept.c thing > is the latest addition. And it is well ugh-worthy. > 1. We can't really simulate the native posix threading libraries; What do you mean by "simulate"? Do you mean we can emulate the presence of the library, but we can't run a simulation of the actual library? What we could do is move Valgrind's thread simulation an abstraction level down, and intercept the clone system call, and then run the "real" thread library on that. Unfortunately that loses the higher-level insight Valgrind gets into the threading behaviour of the target program. > What I am thinking of is this: > > A. Turn V into a bog-standard program, not an LD_PRELOAD thing, > which contains its own ELF loader. This makes (3) go away, and > it gives us complete control of (2). ELF loaders exist; > we might be able to start from Mark Probst's loader in bintrans > if we ask nicely :-) > (http://www.complang.tuwien.ac.at/schani) ELF loaders are easy. There are some complexities though: does Valgrind live in the same address space as the target app, or a separate one? If its the same one, then you get the problem of making two libc's exist in the same address space. If they're in different address spaces, you have the question of how to give Valgrind efficient control of the target address space (which ideally requires OS support in the form of an address space without its own thread - something pretty alien to Linux's model of things). The third option is the compromise: make them logically distinct address spaces, but have them share the same actual address space by adding another virtualization layer on address translation. > B. Now that we have complete control over loading, we can reliably > substitute in our own libpthread.so. Whoa there - you're leaping to conclusions. A implies you have an ELF loader which emulates execve() - ie, user-space exec. But it doesn't necessarily mean you've replaced ld.so and its loading mechanisms (which was already all in user- space). If you do mean replacing ld.so and its resolution mechanism, it means you're willing to actually understand how all that stuff works and 1) emulate it while 2) modifying the behaviour for our purposes. However, I think once you've done 1) you can probably get the existing dynamic linker to do what we need. User-space exec does make it easy to replace ld.so with anything we like, because we can choose to mis-interpret the ET_INTERP program header. > Now, we are going to have to jump through hoops to come up with > another libpthread.so which works properly with NPTL. So > (and this is where you need your barfbags) how about also ignoring > requests to load glibc.so. Instead, we supply our own > implementation > of libc, which probably also contains our integrated pthreads > implementation. If you're actually proposing that we replace glibc with an ABI-compatible re- implementation which happens to not use NPTL, then I think that's a huge amount of work with a lot of disadvantages. We could just package an appropriately built glibc with valgrind itself and use that, but that may still cause more problems than it solves. I think it would help me if someone could explain exactly how NPTL differs from normal pthreads at the ABI level. Why does Valgrind care? What changes are made to the instruction stream? > Um, I don't know if this is a really really stupid idea or not. > Probably is. Please feel free to shoot me down in flames. > (be as rude as you like :) > > It would be nice (in the long run) for V to be more modular. It's > pretty clear that the virtual CPU can be made fairly modular -- > basically, made into a library which translates a source bb into an > instrumented bb. Being modular helps if we want to think about making > a virtual CPU for some other architecture. I definitely agree. The trouble is that V really wants to operate of several levels of abstraction at once. At core it is a CPU/OS syscall emulator, and at that level this proposal makes some sense. However, because Valgrind also does emulation at the library level, it wants to be at the next level up. I think we can probably address this in two parts: 1. make V a full stand-alone CPU/syscall emulator, which is capable of running most programs (even threaded) without having to do any library intercepts, simply by emulating enough of the syscall layer for pthreads to work. 2. Some skins really want to understand what's happening at the library call level rather than the syscall leveL (helgrind, for example, wants to know where and what a lock is). In that case, library intercepts are the only option. We can either do this at the dynamic linker level (ie, what V does now), or perhaps at the CPU level (if you see a call to this address, quietly redirect it through this function). This means that we can avoid all the current complexity. All we need to do is look up the address of pthread_mutex_lock (say), and add that address to an intercept table which the dynamic codegen can consult whenever it is about to generate some code. That intercept table would list a pair of "run before"/"run after" functions which would be inserted into the generated code. J |
|
From: Julian S. <js...@ac...> - 2003-04-07 23:27:37
|
... from the usual place, http://developer.kde.org/~sewardj The release notes follow. J Version 1.9.5 (7 April 2003) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ It occurs to me that it would be helpful for valgrind users to record in the source distribution the changes in each release. So I now attempt to mend my errant ways :-) Changes in this and future releases will be documented in the NEWS file in the source distribution. Major changes in 1.9.5: - (Critical bug fix): Fix a bug in the FPU simulation. This was causing some floating point conditional tests not to work right. Several people reported this. If you had floating point code which didn't work right on 1.9.1 to 1.9.4, it's worth trying 1.9.5. - Partial support for Red Hat 9. RH9 uses the new Native Posix Threads Library (NPTL), instead of the older LinuxThreads. This potentially causes problems with V which will take some time to correct. In the meantime we have partially worked around this, and so 1.9.5 works on RH9. Threaded programs still work, but they may deadlock, because some system calls (accept, read, write, etc) which should be nonblocking, in fact do block. This is a known bug which we are looking into. If you can, your best bet (unfortunately) is to avoid using 1.9.5 on a Red Hat 9 system, or on any NPTL-based distribution. If your glibc is 2.3.1 or earlier, you're almost certainly OK. Minor changes in 1.9.5: - Added some #errors to valgrind.h to ensure people don't include it accidentally in their sources. This is a change from 1.0.X which was never properly documented. The right thing to include is now memcheck.h. Some people reported problems and strange behaviour when (incorrectly) including valgrind.h in code with 1.9.1 -- 1.9.4. This is no longer possible. - Add some __extension__ bits and pieces so that gcc configured for valgrind-checking compiles even with -Werror. If you don't understand this, ignore it. Of interest to gcc developers only. - Removed a pointless check which caused problems interworking with Clearcase. V would complain about shared objects whose names did not end ".so", and refuse to run. This is now fixed. In fact it was fixed in 1.9.4 but not documented. - Fixed a bug causing an assertion failure of "waiters == 1" somewhere in vg_scheduler.c, when running large threaded apps, notably MySQL. - Add support for the munlock system call (124). Some comments about future releases: 1.9.5 is, we hope, the most stable Valgrind so far. It pretty much supersedes the 1.0.X branch. If you are a valgrind packager, please consider making 1.9.5 available to your users. You can regard the 1.0.X branch as obsolete: 1.9.5 is stable and vastly superior. There are no plans at all for further releases of the 1.0.X branch. If you want a leading-edge valgrind, consider building the cvs head (from SourceForge), or getting a snapshot of it. Current cool stuff going in includes MMX support (done); SSE/SSE2 support (in progress), a significant (10-20%) performance improvement (done), and the usual large collection of minor changes. Hopefully we will be able to improve our NPTL support, but no promises. |
|
From: Adam G. <ar...@cy...> - 2003-04-07 14:28:18
|
At 17:28 06/04/03 +0000, Julian Seward wrote: >I've spent the afternoon messing with R H 9. Graydon and Jeff have >done a great job telling me useful stuff for getting V to work on >RH9, and thanks to them for that. > >So it sort-of works. Unfortunately OpenOffice hangs, due to an accept() >call which isn't correctly routed to V's only-this-thread-blocks >implementation thereof, and so the whole app hangs. Sigh. I think it >might be due to ld.so in 9 ignoring -z initfirst. > >It's all a swamp, and V is getting more and more cluttered with stuff >to work around this kind of problem. JeremyF's vg_intercept.c thing >is the latest addition. just as a matter of interest (or maybe shared problems!) WINE has been having trouble with NPTL as well, since they also want to provide their own pthread implementation... might be worth having a look at some of the hoops the new NPTL patches in WINE go through. Seeya, Adam -- Real Programmers don't comment their code. If it was hard to write, it should be hard to read, and even harder to modify. These are all my own opinions. |
|
From: Nicholas N. <nj...@ca...> - 2003-04-07 13:40:40
|
On Sun, 6 Apr 2003, Julian Seward wrote: > Now, we are going to have to jump through hoops to come up with > another libpthread.so which works properly with NPTL. So > (and this is where you need your barfbags) how about also ignoring > requests to load glibc.so. Instead, we supply our own implementation > of libc, which probably also contains our integrated pthreads > implementation. > > Um, I don't know if this is a really really stupid idea or not. > Probably is. Please feel free to shoot me down in flames. > (be as rude as you like :) Whoa, glibc.so is pretty big; the libpthread.so implementation isn't even complete (missing some obscure functions), replacing glibc.so will have that problem but on a much worse scale. Also, this would mean that the program running under Valgrind is even further from the original program than is the case currently, where libpthread.so and malloc() et al are replaced. This seems like a bad idea to me, especially for eg. Cachegrind and any other skins that try to measure aspects of performance. This sounds dangerous to me. What happened to your idea about intercepting clone() but nothing else, and having Valgrind schedule the threads? Is that not possible with NPTL? N |
|
From: Nicholas N. <nj...@ca...> - 2003-04-07 13:32:24
|
On Fri, 4 Apr 2003, Julian Seward wrote: > > BTW, its #warn, not #warning. > > gcc didn't yelp about #warning when I tested, so is #warning OK or not? With #warning, I get a message like this if I #include valgrind.h: In file included from a.c:2: include/valgrind.h:64:4: warning: #warning For valgrind versions 1.9.0 and after, include/valgrind.h:65:4: warning: #warning you should not include valgrind.h directly. include/valgrind.h:66:4: warning: #warning Instead include the .h relevant to the skin include/valgrind.h:67:4: warning: #warning you want to use. For most people this means include/valgrind.h:68:4: warning: #warning you need to include memcheck.h instead of include/valgrind.h:69:4: warning: #warning valgrind.h. include/valgrind.h:70:4: #error Compilation of your source will now abort. It's a little odd that it says "warning: #warning" instead of just "warning: ", but it works. With #warn, it doesn't work: include/valgrind.h:64:4: invalid preprocessing directive #warn include/valgrind.h:65:4: invalid preprocessing directive #warn include/valgrind.h:66:4: invalid preprocessing directive #warn include/valgrind.h:67:4: invalid preprocessing directive #warn include/valgrind.h:68:4: invalid preprocessing directive #warn include/valgrind.h:69:4: invalid preprocessing directive #warn include/valgrind.h:70:4: #error Compilation of your source will now abort. This is with gcc 2.96 and 3.0.4. N |
|
From: Julian S. <js...@ac...> - 2003-04-06 17:21:00
|
I've spent the afternoon messing with R H 9. Graydon and Jeff have
done a great job telling me useful stuff for getting V to work on
RH9, and thanks to them for that.
So it sort-of works. Unfortunately OpenOffice hangs, due to an accept()
call which isn't correctly routed to V's only-this-thread-blocks
implementation thereof, and so the whole app hangs. Sigh. I think it
might be due to ld.so in 9 ignoring -z initfirst.
It's all a swamp, and V is getting more and more cluttered with stuff
to work around this kind of problem. JeremyF's vg_intercept.c thing
is the latest addition.
Seems like time for a clean start. How about this for a suggestion.
Read and barf :-)
-----------------
We have (at least) 3 fundamental problems.
1. We can't really simulate the native posix threading libraries;
i really don't want to get into the problems of making V -- and
more importantly, the code it produces -- thread safe. And it
practice it turns out to be quite useful to be able to intercept
the pthread calls and do our own checking of them anyway. This
means we want to supply our own libpthread.so. At least a simple
implementation of posix pthreads has turned out to be not very
difficult to implement anyway.
2. We have to rely on the LD_PRELOAD mechanism to sneak in our own
libpthread.so (and to gain control at all). This is fragile,
inflexible, and requires us to play games with weak symbols etc
to get the right bindings. Even so it sometimes fails to work
well enough, as with RH9.
3. Using LD_PRELOAD to gain control has worked surprisingly well
for a long time. But it's also a nuisance. It means V has to
be entirely self-contained; we can't use any glibc fns ourselves
and so have to supply vg_mylibc.c, for example. It also more or
less prevents us from writing any parts of V in any other
programming language -- for example, lots of Nick's skin stuff
might be easier done in C++.
What I am thinking of is this:
A. Turn V into a bog-standard program, not an LD_PRELOAD thing,
which contains its own ELF loader. This makes (3) go away, and
it gives us complete control of (2). ELF loaders exist;
we might be able to start from Mark Probst's loader in bintrans
if we ask nicely :-)
(http://www.complang.tuwien.ac.at/schani)
B. Now that we have complete control over loading, we can reliably
substitute in our own libpthread.so.
Now, we are going to have to jump through hoops to come up with
another libpthread.so which works properly with NPTL. So
(and this is where you need your barfbags) how about also ignoring
requests to load glibc.so. Instead, we supply our own implementation
of libc, which probably also contains our integrated pthreads
implementation.
Um, I don't know if this is a really really stupid idea or not.
Probably is. Please feel free to shoot me down in flames.
(be as rude as you like :)
It would be nice (in the long run) for V to be more modular. It's
pretty clear that the virtual CPU can be made fairly modular --
basically, made into a library which translates a source bb into an
instrumented bb. Being modular helps if we want to think about making
a virtual CPU for some other architecture.
Nick's work shows that the instrumentation system(s) can be made modular.
So, finally, it would be nice to modularise, as best
we can, that part of it which constructs the environment in which
the simulated program is to run. This seems to me to be a step in
the right direction.
Comments? This is obviously a large amount of work, and I'd be
interested in hearing opinions of how to ensure the longer-term
maintainability of V.
J
|
|
From: Julian S. <js...@ac...> - 2003-04-06 12:56:51
|
Oops! LD_ASSUME_KERNEL=2.2.5 totally breaks things on my SuSE box. Is there a standard configure test which I can use to determine if this is an NPTL-based system, and make the LD_ASSUME_KERNEL thing conditional on that? I might be able to devise one, but I assume you folks will have a standard test already. Thanks, J |