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: 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 |