Re: 4.3.4-dev-6

Re: 4.3.4-dev-6

[Clint Adams]

On Thu, Dec 20, 2007 at 02:07:41PM +0000, Peter Stephenson wrote:
> ftp://ftp.zsh.org/pub/development/zsh-4.3.4-dev-6.tar.gz

This has been failing forever, but 24290 has made it less
ignorable.

This occurs when being built chrooted by either a perl or bash script, with output possibly 
redirected or piped to tee.

../../Test/A04redirect.ztst: starting.
*** /tmp/zsh.ztst.out.23912     Thu Dec 20 15:28:39 2007
--- /tmp/zsh.ztst.tout.23912    Thu Dec 20 15:28:39 2007
***************
*** 0 ****
--- 1 ----
+ foo
Test ../../Test/A04redirect.ztst failed: output differs from expected as shown above for:
  print foo >&-
Was testing: '>&-' redirection
../../Test/A04redirect.ztst: test failed.

Re: 4.3.4-dev-6

[Peter Stephenson]

On Thu, 20 Dec 2007 15:58:23 -0500
Clint Adams <schizo@debian.org> wrote:
> > ftp://ftp.zsh.org/pub/development/zsh-4.3.4-dev-6.tar.gz
> 
> This has been failing forever, but 24290 has made it less
> ignorable.
> 
> This occurs when being built chrooted by either a perl or bash script,
> with output possibly redirected or piped to tee.
> 
> ../../Test/A04redirect.ztst: starting.
> *** /tmp/zsh.ztst.out.23912     Thu Dec 20 15:28:39 2007
> --- /tmp/zsh.ztst.tout.23912    Thu Dec 20 15:28:39 2007
> ***************
> *** 0 ****
> --- 1 ----
> + foo
> Test ../../Test/A04redirect.ztst failed: output differs from expected as shown above for:
>   print foo >&-
> Was testing: '>&-' redirection
> ../../Test/A04redirect.ztst: test failed.

I suggest breakpointing where REDIR_CLOSE is handled around line 2708 of
exec.c in such an environment (which I don't have) to see what's happening.
I suppose it's just vaguely possible that stdin has been set up as a
multio for some reason:  addfd() is the function that adds to a multio
and closemn() is where they are actually spawned (it's quite badly named).

I'm likely to be offline for most of the next couple of weeks.

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: 4.3.4-dev-6

[Clint Adams]

On Fri, Dec 21, 2007 at 06:49:32PM +0000, Peter Stephenson wrote:
> I suggest breakpointing where REDIR_CLOSE is handled around line 2708 of
> exec.c in such an environment (which I don't have) to see what's happening.
> I suppose it's just vaguely possible that stdin has been set up as a
> multio for some reason:  addfd() is the function that adds to a multio
> and closemn() is where they are actually spawned (it's quite badly named).

That was a bit of a red herring; I have the exact same problem with a
normal make & make check.  I wonder if this has something to do with it:

%   mkdir redir.tmp && cd redir.tmp
% 
%   myfd=99
%   (echo >&$myfd) 2>msg
%   bad_fd_msg="${$(<msg)##*:}"
%   print foo >&-
% cat msg
zsh: 99: bad file descriptor
% <Ctrl-D to exit shell>
foo

Re: 4.3.4-dev-6

[Peter Stephenson]

On Sat, 22 Dec 2007 13:09:31 -0500
Clint Adams <schizo@debian.org> wrote:
> %   mkdir redir.tmp && cd redir.tmp
> % 
> %   myfd=99
> %   (echo >&$myfd) 2>msg
> %   bad_fd_msg="${$(<msg)##*:}"
> %   print foo >&-
> % cat msg
> zsh: 99: bad file descriptor
> % <Ctrl-D to exit shell>
> foo

I'm not getting that last "foo"; could there be a race somewhere, or a
non-standard configuration option set that's doing something odd with
file descriptors, or something nasty in the compilation tree?

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: 4.3.4-dev-6

[Clint Adams]

On Thu, Jan 03, 2008 at 05:08:24PM +0000, Peter Stephenson wrote:
> I'm not getting that last "foo"; could there be a race somewhere, or a
> non-standard configuration option set that's doing something odd with
> file descriptors, or something nasty in the compilation tree?

Straight CVS, Util/preconfig,
./configure --with-term-lib=ncursesw --prefix=/usr CFLAGS=-O2 -ggdb -Wall
make
make check

glibc 2.7, gcc 4.2.3 prerelease, Linux 2.6.21

possible glibc bug with buffers [was Re: 4.3.4-dev-6]

[Clint Adams]

On Thu, Jan 03, 2008 at 05:08:24PM +0000, Peter Stephenson wrote:
> I'm not getting that last "foo"; could there be a race somewhere, or a
> non-standard configuration option set that's doing something odd with
> file descriptors, or something nasty in the compilation tree?

My current understanding of the situation is as follows:
bash, ksh, and zsh behave normally under glibc 2.3

under glibc 2.7, ksh behaves normally

bash does this
$ echo one >/dev/full
bash: echo: write error: No space left on device
$ echo two
one
two

and zsh does this
% echo one >/dev/full
echo: write error: no space left on device
one
% echo two
two

I can't reproduce this with a simple fprintf-ing to /dev/full.

Re: possible glibc bug with buffers [was Re: 4.3.4-dev-6]

[Ismail Dönmez]

Monday 07 January 2008 21:44:21 tarihinde Clint Adams şunları yazmıştı:
> and zsh does this
> % echo one >/dev/full
> echo: write error: no space left on device
> one
> % echo two
> two

Uhm glibc 2.7 with some patches, and zsh from CVS:

[~]> echo one >/dev/full
echo: write error: no space left on device
[~]>  echo two
two

regards,
ismail

-- 
Never learn by your mistakes, if you do you may never dare to try again.

Re: possible glibc bug with buffers [was Re: 4.3.4-dev-6]

[Andrey Borzenkov]

[-- Attachment #1.1: Type: text/plain, Size: 942 bytes --]

On Monday 07 January 2008, Clint Adams wrote:
> 
> On Thu, Jan 03, 2008 at 05:08:24PM +0000, Peter Stephenson wrote:
> > I'm not getting that last "foo"; could there be a race somewhere, or a
> > non-standard configuration option set that's doing something odd with
> > file descriptors, or something nasty in the compilation tree?
> 
> My current understanding of the situation is as follows:
> bash, ksh, and zsh behave normally under glibc 2.3
> 
> under glibc 2.7, ksh behaves normally
> 
> bash does this
> $ echo one >/dev/full
> bash: echo: write error: No space left on device
> $ echo two
> one
> two
> 
> and zsh does this
> % echo one >/dev/full
> echo: write error: no space left on device
> one
> % echo two
> two
> 
> I can't reproduce this with a simple fprintf-ing to /dev/full.
> 
> 
> 
> 

this is being discussed right now on linux-hotplug as well; there is also Debian 
bug report on it.

[-- Attachment #1.2: Andrew Patterson <andrew.patterson@hp.com>: Re: Error returns not handled	correctly	by	sysfs.c:subsys_attr_store() --]
[-- Type: message/rfc822, Size: 5557 bytes --]

From: Andrew Patterson <andrew.patterson@hp.com>
To: Tejun Heo <teheo@suse.de>
Cc: Greg KH <greg@kroah.com>, Andrew Morton <akpm@linux-foundation.org>, linux-kernel@vger.kernel.org, linux-hotplug@vger.kernel.org, bjorn.helgaas@hp.com
Subject: Re: Error returns not handled	correctly	by	sysfs.c:subsys_attr_store()
Date: Mon, 07 Jan 2008 14:13:33 -0700
Message-ID: <1199740413.7025.83.camel@bluto.andrew>

On Thu, 2008-01-03 at 17:17 -0700, Andrew Patterson wrote:
> On Fri, 2008-01-04 at 09:07 +0900, Tejun Heo wrote:
> > Hello,
> > 
> > Andrew Patterson wrote:
> > > It looks like this is a shell issue.  After looking through the sysfs
> > > code, I realized that this problem seems to be driven from user-land.
> > > So I performed some experiments:
> > > 
> > >      1. Wrote a simple program that just used write(2) to write to the
> > >         sysfs entry. This works fine.
> > >      2. Used /bin/echo instead of the built-in echo command.  This too
> > >         works fine.
> > >      3. Tried several shells.  Zsh and Bash both fail.  Csh works fine.
> > > 
> > > I then ran strace on the following shell-script:
> > > 
> > > #!/bin/bash
> > > 
> > > echo x > allow_restart
> > > echo y > allow_restart
> > > echo z > allow_restart
> > > 
> > > and got:
> > > 
> > > # strace -e trace=write ~/tmp/tester.sh 
> > > write(1, "x\n", 2)                      = -1 EINVAL (Invalid argument)
> > > write(1, "x\n", 2)                      = -1 EINVAL (Invalid argument)
> > > write(2, "/home/andrew/tmp/tester.sh: line"..., 72/home/andrew/tmp/tester.sh: line 4: echo: write error: Invalid argument
> > > ) = 72
> > > write(1, "x\ny\n", 4)                   = -1 EINVAL (Invalid argument)
> > > write(1, "x\ny\n", 4)                   = -1 EINVAL (Invalid argument)
> > > write(2, "/home/andrew/tmp/tester.sh: line"..., 72/home/andrew/tmp/tester.sh: line 5: echo: write error: Invalid argument
> > > ) = 72
> > > write(1, "x\ny\nz\n", 6)                = -1 EINVAL (Invalid argument)
> > > write(1, "x\ny\nz\n", 6)                = -1 EINVAL (Invalid argument)
> > > write(2, "/home/andrew/tmp/tester.sh: line"..., 72/home/andrew/tmp/tester.sh: line 6: echo: write error: Invalid argument
> > > ) = 72
> > > write(1, "x\ny\nz\n", 6x
> > > y
> > > z
> > > )                = 6
> > > Process 3800 detached
> > 
> > Eeeeeeeekkkk.... That's scary.  Which distro are you using and what does
> > 'bash --version' say?
> 
> IA64 Debian lenny.  
> 
> # bash --version
> GNU bash, version 3.1.17(1)-release (ia64-unknown-linux-gnu)
> 
> # zsh --version 
> zsh 4.3.4 (ia64-unknown-linux-gnu)
> 
> # csh --version
> tcsh 6.14.00 (Astron) 2005-03-25 (ia64-unknown-linux) options
> wide,nls,dl,al,kan,rh,nd,color,filec
> 
> I suppose I should try this an ia32 box again, and perhaps with some
> other distros.  I am not sure what the kernel can do about this, but it
> might be nice to report it to the shell maintainers.
> 

This looks like it might be the culprit. 

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=459643

The fact that it works on SLES10 lends further evidence to glibc being
the problem.

-- 
Andrew Patterson
Hewlett-Packard Company

-
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: possible glibc bug with buffers [was Re: 4.3.4-dev-6]

[Clint Adams]

On Tue, Jan 08, 2008 at 10:17:36AM +0300, Andrey Borzenkov wrote:
> this is being discussed right now on linux-hotplug as well; there is also Debian 
> bug report on it.

Thanks, this is a Debian-specific problem.
http://sourceware.org/bugzilla/show_bug.cgi?id=4656

working around dietlibc or patched glibc [Re: possible glibc bug with buffers]

[Clint Adams]

On Wed, Jan 09, 2008 at 01:36:20PM -0500, Clint Adams wrote:
> Thanks, this is a Debian-specific problem.
> http://sourceware.org/bugzilla/show_bug.cgi?id=4656

In further news, I am told that anyone linking zsh against
dietlibc will encounter the same issues and that one can
use fpurge/__fpurge (not portable) on error to achieve consistency.