From: Andrey Borzenkov <arvidjaar@newmail.ru>
To: zsh-workers@sunsite.dk
Subject: Re: possible glibc bug with buffers [was Re: 4.3.4-dev-6]
Date: Tue, 8 Jan 2008 10:17:36 +0300 [thread overview]
Message-ID: <200801081017.36828.arvidjaar@newmail.ru> (raw)
In-Reply-To: <20080107194421.GA26236@scowler.net>
[-- 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 --]
next prev parent reply other threads:[~2008-01-08 7:17 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <5951.1198159661@csr.com>
2007-12-20 20:58 ` 4.3.4-dev-6 Clint Adams
2007-12-21 18:49 ` 4.3.4-dev-6 Peter Stephenson
2007-12-22 18:09 ` 4.3.4-dev-6 Clint Adams
2008-01-03 17:08 ` 4.3.4-dev-6 Peter Stephenson
2008-01-04 4:23 ` 4.3.4-dev-6 Clint Adams
2008-01-07 19:44 ` possible glibc bug with buffers [was Re: 4.3.4-dev-6] Clint Adams
2008-01-07 20:01 ` Ismail Dönmez
2008-01-08 7:17 ` Andrey Borzenkov [this message]
2008-01-09 18:36 ` Clint Adams
2008-01-09 19:27 ` working around dietlibc or patched glibc [Re: possible glibc bug with buffers] Clint Adams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200801081017.36828.arvidjaar@newmail.ru \
--to=arvidjaar@newmail.ru \
--cc=zsh-workers@sunsite.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).