headers
dholland | 1 Sep 2010 05:22
Picon

Re: bin/43821 (make: oldstanding bug with loop variables)

Synopsis: make: oldstanding bug with loop variables

State-Changed-From-To: open->suspended
State-Changed-By: dholland <at> NetBSD.org
State-Changed-When: Wed, 01 Sep 2010 03:22:53 +0000
State-Changed-Why:
Whether it's a bug is debatable (getting "malformed conditional" is a bug
but that's a minor aspect of the issue) but this is deeply ingrained
behavior of loop variables and it's not readily changed or "fixed". Try
this example on for size:

.for i in 1 2 3
j=${i}       
.if !empty(j:M2)
res=passed ${j}
.endif  
.endfor

 all:
	 <at> echo ${res}
Permalink | Reply | 1 comment |
headers
Matthew Mondor | 1 Sep 2010 07:25

xsrc/43824: -current xsrc has a broken XShm.h header file

>Number:         43824
>Category:       xsrc
>Synopsis:       -current xsrc has a broken XShm.h header file
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    xsrc-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Sep 01 05:25:00 +0000 2010
>Originator:     Matthew Mondor
>Release:        -current
>Organization:
>Environment:
>Description:

According to the XShm(3) manual page, and a practice which is common is
to include XShm.h and expect that it's enough for related function
prototypes to also be declared.  However, on -current this is not the
case and one must explicitely add an include for shmproto.h.

The fix simply makes XShm.h implicitely include the internal shmproto.h
header file.  This is what FreeBSD also did after their upgrade to XOrg
7.5.  This makes software using the MIT-SHM extension work again on
-current.

>How-To-Repeat:

Attempt to build a package making use of MIT-SHM on -current with
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bernd Ernesti | 1 Sep 2010 08:10
Picon

Re: xsrc/43824: -current xsrc has a broken XShm.h header file

The following reply was made to PR xsrc/43824; it has been noted by GNATS.

From: Bernd Ernesti <veego <at> NetBSD.org>
To: gnats-bugs <at> NetBSD.org
Cc: 
Subject: Re: xsrc/43824: -current xsrc has a broken XShm.h header file
Date: Wed, 1 Sep 2010 08:07:26 +0200

 On Wed, Sep 01, 2010 at 05:25:01AM +0000, Matthew Mondor wrote:
 [..]

 > >Fix:
 > 
 > --- xsrc/external/mit/libXext/dist/include/X11/extensions/XShm.h.orig	2010-06-15
23:05:43.000000000 -0400
 > +++ xsrc/external/mit/libXext/dist/include/X11/extensions/XShm.h	2010-09-01
01:06:48.000000000 -0400
 >  <at>  <at>  -34,6 +34,7  <at>  <at> 
 >  
 >  #include <X11/Xfuncproto.h>
 >  #include <X11/extensions/shm.h>
 > +#include <X11/extensions/shmproto.h>
 >  
 >  #ifndef _XSHM_SERVER_
 >  typedef unsigned long ShmSeg;

 I don't like that. Yes the behaviour change is broken but it doesn't mean
 we should maintain our own patches again forever.

 Bernd
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matthew Mondor | 1 Sep 2010 08:35

Re: xsrc/43824: -current xsrc has a broken XShm.h header file

The following reply was made to PR xsrc/43824; it has been noted by GNATS.

From: Matthew Mondor <mm_lists <at> pulsar-zone.net>
To: gnats-bugs <at> NetBSD.org
Cc: 
Subject: Re: xsrc/43824: -current xsrc has a broken XShm.h header file
Date: Wed, 1 Sep 2010 02:30:21 -0400

 On Wed,  1 Sep 2010 06:10:05 +0000 (UTC)
 Bernd Ernesti <veego <at> NetBSD.org> wrote:

 >  I don't like that. Yes the behaviour change is broken but it doesn't mean
 >  we should maintain our own patches again forever.

 I understand, and also notified tech-x11 of this PR so that hopefully
 someone with a foot upstream can decide what to do.  IMO the change
 also should be made upstream (if it's not already), and I don't
 understand what the intention was if it was a deliberate interface
 change.

 Oh and I forgot to refer to the other related PR, here it is: pkg/43811

 Thanks,
 -- 
 Matt
Permalink | Reply | 0 comments |
headers
Aleksey Cheusov | 1 Sep 2010 09:09
Picon
Favicon

Re: bin/43821 (make: oldstanding bug with loop variables)

> Whether it's a bug is debatable (getting "malformed conditional" is a bug
> but that's a minor aspect of the issue) but this is deeply ingrained
> behavior of loop variables and it's not readily changed or "fixed".
From the documentation it is unclear that loop variables cannot be used
in condition statements directly just like normal variables. So,
formally speaking, it is definitely a bug. If it is really really
impossible to fix it, then it should be documented ;-) As for your
example code, of course I know about such a workaround. My original post
contained mostly the same fragment. I also know when variables are
expanded but loop variable expansion doesn't relate to this PR.

http://mail-index.netbsd.org/tech-userlevel/2010/06/08/msg003690.html
http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.bin/make/make.1.diff?r1=1.174&r2=1.175&only_with_tag=MAIN&f=h

> Try this example on for size:

> .for i in 1 2 3
> j=${i}       
> .if !empty(j:M2)
> res=passed ${j}
> .endif  
> .endfor

>  all:
> 	 <at> echo ${res}

--

-- 
Best regards, Aleksey Cheusov.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Aleksey Cheusov | 1 Sep 2010 09:15
Picon
Favicon

Re: bin/43821 (make: oldstanding bug with loop variables)

The following reply was made to PR bin/43821; it has been noted by GNATS.

From: Aleksey Cheusov <cheusov <at> tut.by>
To: gnats-bugs <at> NetBSD.org
Cc: gnats-admin <at> netbsd.org, netbsd-bugs <at> netbsd.org, dholland <at> NetBSD.org
Subject: Re: bin/43821 (make: oldstanding bug with loop variables)
Date: Wed, 01 Sep 2010 10:09:46 +0300

 > Whether it's a bug is debatable (getting "malformed conditional" is a bug
 > but that's a minor aspect of the issue) but this is deeply ingrained
 > behavior of loop variables and it's not readily changed or "fixed".
 From the documentation it is unclear that loop variables cannot be used
 in condition statements directly just like normal variables. So,
 formally speaking, it is definitely a bug. If it is really really
 impossible to fix it, then it should be documented ;-) As for your
 example code, of course I know about such a workaround. My original post
 contained mostly the same fragment. I also know when variables are
 expanded but loop variable expansion doesn't relate to this PR.

 http://mail-index.netbsd.org/tech-userlevel/2010/06/08/msg003690.html
 http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.bin/make/make.1.diff?r1=1.174&r2=1.175&only_with_tag=MAIN&f=h

 > Try this example on for size:

 > .for i in 1 2 3
 > j=${i}       
 > .if !empty(j:M2)
 > res=passed ${j}
 > .endif  
 > .endfor
(Continue reading)

Permalink | Reply | 0 comments |
headers
guy | 1 Sep 2010 10:15
Picon
Favicon

lib/43825: p->cc can go negative in libpcap

>Number:         43825
>Category:       lib
>Synopsis:       p->cc can go negative in libpcap
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    lib-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Sep 01 08:15:01 +0000 2010
>Originator:     Guy Harris
>Release:        Top of tree
>Organization:
>Environment:
>Description:
In pcap_read_bpf(), ep is set based on the return value of read(), but read() from a BPF device doesn't
necessarily return a value that's a multiple of the alignment value for BPF_WORDALIGN(). However,
whenever we increment bp, we round up the increment value by a value rounded up by BPF_WORDALIGN(), so we
could increment bp past ep after processing the last packet in the buffer.

(The patch also fixes the case where it returns due to a pcap_breakloop() call, so it doesn't re-process packets.)
>How-To-Repeat:
Run a program that opens a capture device with a timeout of 0, in a loop, calls pcap_dispatch() with a cnt
argument of 1, and reports when it returns a value of 0. The timeout of 0 means that the read() that libpcap
does shouldn't return until there's packet data, so a timeout won't cause pcap_dispatch() to return 0. Do
a large amount of network data transfer, to fill up the BPF bucket; notice that, on occasion, the program
will report that pcap_dispatch() returns 0.
>Fix:
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Laight | 1 Sep 2010 11:50
Picon

Re: bin/43821: make: longstanding bug with loop variables

The following reply was made to PR bin/43821; it has been noted by GNATS.

From: David Laight <david <at> l8s.co.uk>
To: gnats-bugs <at> NetBSD.org
Cc: 
Subject: Re: bin/43821: make: longstanding bug with loop variables
Date: Wed, 1 Sep 2010 10:53:01 +0100

 On Tue, Aug 31, 2010 at 12:20:01PM +0000, cheusov <at> tut.by wrote:
 > >Number:         43821
 > >Category:       bin
 > >Synopsis:       make: oldstanding bug with loop variables
 ...
 > >Description:
 > 
 >     .for i in 1 2
 >     .if empty(i:M2)
 >     res=passed
 >     .endif
 >     .endfor
 ...

 The 'problem' is that the code that substitutes the loop variables
 into the loop body before the body is parsed (yes it does work that way)
 doesn't identify empty(...) as equivalent to $(...) and modify the text.

 Since empty() is just a comparison against "" there is a trivial
 work around.

 A better fix is to rework the .for handling (again) so that the loop
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chuck Silvers | 1 Sep 2010 19:00
Picon

PR/40389 CVS commit: src/sys

The following reply was made to PR kern/40389; it has been noted by GNATS.

From: Chuck Silvers <chs <at> netbsd.org>
To: gnats-bugs <at> gnats.NetBSD.org
Cc: 
Subject: PR/40389 CVS commit: src/sys
Date: Wed, 1 Sep 2010 16:56:20 +0000

 Module Name:	src
 Committed By:	chs
 Date:		Wed Sep  1 16:56:20 UTC 2010

 Modified Files:
 	src/sys/miscfs/genfs: genfs_io.c genfs_node.h genfs_vnops.c
 	src/sys/ufs/ufs: ufs_inode.c
 	src/sys/uvm: uvm_pager.h

 Log Message:
 replace the earlier workaround for PR 40389 with a better fix.
 the earlier change caused data corruption by freeing pages
 without invaliding their mappings.  instead of the trylock/retry,
 just take the genfs-node lock before calling VOP_GETPAGES()
 and pass a new flag to tell it that we're already holding this lock.

 
 To generate a diff of this commit:
 cvs rdiff -u -r1.39 -r1.40 src/sys/miscfs/genfs/genfs_io.c
 cvs rdiff -u -r1.19 -r1.20 src/sys/miscfs/genfs/genfs_node.h
 cvs rdiff -u -r1.182 -r1.183 src/sys/miscfs/genfs/genfs_vnops.c
 cvs rdiff -u -r1.82 -r1.83 src/sys/ufs/ufs/ufs_inode.c
(Continue reading)

Permalink | Reply | 0 comments |
headers
chs | 1 Sep 2010 19:10
Picon

Re: kern/40389 (page busy vs. glock deadlock)

Synopsis: page busy vs. glock deadlock

State-Changed-From-To: analyzed->closed
State-Changed-By: chs <at> NetBSD.org
State-Changed-When: Wed, 01 Sep 2010 17:10:12 +0000
State-Changed-Why:
fixed now.
Permalink | Reply | 0 comments |

Gmane