Hi!
On 11/28/2013 02:32 PM, Flene TOUMANI wrote:
> Is it possible to get a feedback on the issue? (E.g. a confirmation that this
> is a bug).
Sounds like you've run into this problem (patch available):
http://lists.gnu.org/archive/html/bug-bash/2013-10/msg00114.html
/haubi/
On 11/14/2013 08:56 PM, Chet Ramey wrote:
> On 11/8/13 6:26 PM, John Dawson wrote:
>> The following surprised me. I thought line 4 of the output, and certainly
>> line 5 of the output, should have said "0 /dev/fd/63" too. Is this behavior
>> a bug?
>
> I'm still looking at this. I have not had a
When /dev/fd is missing, and named pipes are used instead (like on AIX),
this snippet sometimes does work right, wrong, or hang - depending on
the operating system's process scheduler timing:
for x in {0..9}; do echo $x; done > >(
cnt=0; while read line; do let cnt=cnt+1; done; echo $cnt
)
On 08/28/2012 09:21 AM, Roman Rakus wrote:
> On 08/01/2012 03:13 PM, Chet Ramey wrote:
>> On 7/30/12 10:41 AM, Roman Rakus wrote:
>>
>>> Hmm... I don't know much about boundaries of maximum number of user
>>> processes. But anyway - do you think that (re)changing js.c_childmax (when
>>> `ulimit -u
On 07/29/2012 12:46 AM, Chet Ramey wrote:
> On 7/27/12 9:50 AM, Michael Haubenwallner wrote:
>
>> With attached patch I haven't been able to break the testcase below so far
>> on that AIX 6.1 box here.
>>
>> But still, the other one using the $()-childs still
On 07/26/2012 11:37 PM, Michael Haubenwallner wrote:
> On 07/26/12 20:29, Chet Ramey wrote:
>> OK, we have some data, we have a hypothesis, and we have a way to test it.
>> Let's test it.
>>
>> Michael, please apply the attached patch, disable RECYCLES_PIDS, an
On 07/26/12 20:29, Chet Ramey wrote:
OK, we have some data, we have a hypothesis, and we have a way to test it.
Let's test it.
Michael, please apply the attached patch, disable RECYCLES_PIDS, and run
your tests again. This makes the check for previously-saved exit statuses
unconditional.
Let'
On 07/25/12 19:06, Chet Ramey wrote:
Well, _SC_CHILD_MAX is documented across platforms as:
Heck, even POSIX specifies CHILD_MAX as:
"Maximum number of simultaneous processes per real user ID."
Also, one Linux machine actually shows the _SC_CHILD_MAX value equal to
kernel.pid_max (32768 here
On 07/25/2012 04:50 PM, Chet Ramey wrote:
>> The AIX 6.1 I've debugged on has:
>> #define CHILD_MAX 128
>> #define _POSIX_CHILD_MAX 25
>> sysconf(_SC_CHILD_MAX) = 1024
> Bash prefers sysconf(_SC_CHILD_MAX) and will use it over the other
> defines (lib/sh/oslib.c:getmaxchild()). I don't kno
On 07/25/2012 03:20 PM, Michael Haubenwallner wrote:
> On 07/25/2012 09:59 AM, Michael Haubenwallner wrote:
>> On 07/25/2012 03:05 AM, Chet Ramey wrote:
>>> Bash holds on to the status of all terminated processes, not just
>>> background ones, and only checks for the
On 07/25/2012 02:14 PM, Greg Wooledge wrote:
> On Wed, Jul 25, 2012 at 09:59:28AM +0200, Michael Haubenwallner wrote:
>> OTOH, AFAICT, as long as a PID isn't waitpid()ed for, it isn't reused by
>> fork().
>> However, I'm unable to find that in the POSIX s
On 07/25/2012 09:59 AM, Michael Haubenwallner wrote:
> On 07/25/2012 03:05 AM, Chet Ramey wrote:
>> Bash holds on to the status of all terminated processes, not just
>> background ones, and only checks for the presence of a newly-forked PID
>> in that list if the list s
On 07/25/2012 03:05 AM, Chet Ramey wrote:
> Bash assumes that there's a PID space at least as
> large as CHILD_MAX, and that the kernel will use all of it before reusing
> any PID in the space. Posix says that shells must remember up to CHILD_MAX
> statuses of terminated asynchronous children (th
On 07/24/2012 05:49 PM, Greg Wooledge wrote:
> On Tue, Jul 24, 2012 at 05:03:36PM +0200, michael.haubenwall...@salomon.at
> wrote:
>> Description:
>> On AIX (5.3, 6.1, 7.1), as well as on Interix (any version) I do
>> encounter
>> some race condition in a code similar to:
>> i
Configuration Information [Automatically generated, do not change]:
Machine: powerpc
OS: aix5.3.0.0
Compiler: powerpc-ibm-aix5.3.0.0-gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='powerpc'
-DCONF_OSTYPE='aix5.3.0.0' -DCONF_MACHTYPE='powerpc-ibm-aix5.3.0.0'
-DCONF_VENDOR='ibm' -DLOCALE
On Wed, 2008-07-30 at 18:53 +0200, Michael Haubenwallner wrote:
> Hi,
>
> have some strange race condition here on aix5.3 with bash-3.2.39, when
> using CONFIG_SHELL=/path/to/bash, building in parallel (-j16) with
> libtool. It works when using /bin/ksh.
Now it has happened wi
On Wed, 2008-07-30 at 18:53 +0200, Michael Haubenwallner wrote:
> Now I can see (stripped the unimportant):
> open("GetWMCMapW.loT", O_WRONLY|O_CREAT|O_APPEND|O_LARGEFILE) = 4
> kfcntl(4, 14, 0x0001) = 1
> close(4)= 0
>
ltmain.sh - GNU libtool 1.5.26 (1.1220.2.493 2008/02/01
16:58:18)
#
# Please DO NOT delete this file!
# It is necessary for linking the library.
# Name of the PIC object.
# Name of the non-PIC object.
non_pic_object=none
Thoughts?
Thanks!
/haubi/
--
Michael Haubenwallner
Gentoo on a different level
On Wed, 2008-01-23 at 17:45 +0100, Philippe De Muyter wrote:
> here is a patch :
LOL - this is a very similar patch as
http://lists.gnu.org/archive/html/bug-bash/2007-12/msg00084.html
/haubi/
--
Michael Haubenwallner
Gentoo on a different level
On Sat, 2007-12-22 at 10:13 -0500, Chet Ramey wrote:
> Michael Haubenwallner wrote:
> >> It is because readdir() returns 0 (zero) for (struct dirent).(d_ino),
> >> while stat() returns useful values for (struct stat).(st_ino), so their
> >> equal-comparison never suc
On Fri, 2007-12-21 at 13:51 +0100, Michael Haubenwallner wrote:
> On Thu, 2007-12-20 at 08:08 -0500, Chet Ramey wrote:
> > Michael Haubenwallner wrote:
> > > Machine: i586
> > > OS: interix5.2
> > > Compiler: gcc
> > > Compilation CF
On Thu, 2007-12-20 at 08:08 -0500, Chet Ramey wrote:
> Michael Haubenwallner wrote:
> > Machine: i586
> > OS: interix5.2
> > Compiler: gcc
> > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i586'
> > -DCONF_OSTYPE='interix5.2&#
On Thu, 2007-12-20 at 12:30 +0100, Andreas Schwab wrote:
> Michael Haubenwallner <[EMAIL PROTECTED]> writes:
>
> > diff -ru builtins/common.c builtins/common.c
> > --- builtins/common.c Wed Dec 19 10:30:07 2007
> > +++ builtins/common.c Wed Dec 19 10:34
ory
Fix: (patch attached)
builtins/common.c:
Do not depend on getcwd() doing buffer allocation.
config-bot.h:
Ignore GETCWD_BROKEN, keep HAVE_GETCWD as is.
Additionally, the check for GETCWD_BROKEN can be dropped
from configure.in and aclocal.m4.
Thanks!
/haubi/
--
Micha
24 matches
Mail list logo
