Re: EXTERNAL SENDER: Re: Fork errors

ssage- From: Cygwin On Behalf Of Mark Geisert via Cygwin Sent: Wednesday, September 6, 2023 6:32 PM To: Cygwin Mailing List Subject: EXTERNAL SENDER: Re: Fork errors Dale Lobb via Cygwin wrote: Since upgrading to the latest version of Cygwin a few weeks ago on a server I manage, I&#x

RE: EXTERNAL SENDER: Re: Fork errors

> -Original Message- > From: Cygwin > On Behalf Of Mark Geisert via Cygwin > Sent: Wednesday, September 6, 2023 6:32 PM > To: Cygwin Mailing List > Subject: EXTERNAL SENDER: Re: Fork errors > > Dale Lobb via Cygwin wrote: > >Since upgrading to the latest

RE: EXTERNAL SENDER: RE: Fork errors

> -Original Message- > From: Jose Isaias Cabrera > Sent: Wednesday, September 6, 2023 4:04 PM > To: Jose Isaias Cabrera ; Dale Lobb > ; tryandbuy via Cygwin > Subject: EXTERNAL SENDER: RE: Fork errors > > On September 6, 2023 5:01 PM, Jose Isaias Cabrera e

RE: EXTERNAL SENDER: RE: Fork errors

> -Original Message- > From: Jose Isaias Cabrera > Sent: Wednesday, September 6, 2023 4:01 PM > To: Dale Lobb ; tryandbuy via Cygwin > > Subject: EXTERNAL SENDER: RE: Fork errors > > On September 6, 2023 2:52 PM, Dale Lobb expressed: > > > > Sinc

Re: Fork errors

Bill Stewart via Cygwin wrote: On Wed, Sep 6, 2023 at 5:32 PM Mark Geisert wrote: Speculation: The specific exit code 0xC142 may or may not have something to do with Windows error 142, which is ERROR_BUSY_DRIVE. I cannot help further on this. Correction: The low word of 0xC142 = hex 1

Re: Fork errors

On Wed, Sep 6, 2023 at 5:32 PM Mark Geisert wrote: Speculation: The specific exit code 0xC142 may or may not have > something to do > with Windows error 142, which is ERROR_BUSY_DRIVE. I cannot help further > on this. > Correction: The low word of 0xC142 = hex 142 = decimal 322 = ERROR_D

Re: Fork errors

Dale Lobb via Cygwin wrote: Since upgrading to the latest version of Cygwin a few weeks ago on a server I manage, I've been experiencing an issue with fork errors. The Cygwin installation had not been updated for almost a year before that. The issue happens every time a scri

RE: Fork errors

On September 6, 2023 5:01 PM, Jose Isaias Cabrera expressed: > > > On September 6, 2023 2:52 PM, Dale Lobb expressed: > > > > Since upgrading to the latest version of Cygwin a few weeks ago on a > > server I manage, I've been experiencing an issue with fork err

RE: Fork errors

On September 6, 2023 2:52 PM, Dale Lobb expressed: > > Since upgrading to the latest version of Cygwin a few weeks ago on a > server I manage, I've been experiencing an issue with fork errors. > The Cygwin installation had not been updated for almost a year > before

Fork errors

Since upgrading to the latest version of Cygwin a few weeks ago on a server I manage, I've been experiencing an issue with fork errors. The Cygwin installation had not been updated for almost a year before that. The issue happens every time a script is invoked that purges files from

Re: Apache Fork Errors - Found on Windows Server 2019

I just tried the new packages (using the previous build method, with no circular dependency), and it appears that everything is working properly again. Thank you! -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https:/

Re: Apache Fork Errors - Found on Windows Server 2019

On 10/18/2021 9:43 PM, OwN-3m-All via Cygwin wrote: I upgraded both libharfbuzz0 and libfreetype6 to the latest version again, and the issues are back. I tested these previous versions for both, and they work: libharfbuzz0 2.7.4-1 and 2.8.1-1 work libfreetype6 2.10.4-1 and 2.10.4-2 work The la

Re: Apache Fork Errors - Found on Windows Server 2019

I upgraded both libharfbuzz0 and libfreetype6 to the latest version again, and the issues are back. I tested these previous versions for both, and they work: libharfbuzz0 2.7.4-1 and 2.8.1-1 work libfreetype6 2.10.4-1 and 2.10.4-2 work The latest versions of these libs need to be reverted or pro

Re: Apache Fork Errors - Found on Windows Server 2019

On 10/18/2021 4:43 PM, OwN-3m-All via Cygwin wrote: Since those are the two DLLs that are causing a problem for you, maybe that circular dependency doesn't work well on Cygwin for some reason. Please try downgrading to the previous versions of harfbuzz and freetype2 and see if that fixes t

Re: Apache Fork Errors - Found on Windows Server 2019

> Since those are the two DLLs that are causing a problem for you, maybe that > circular dependency doesn't work well on Cygwin for some reason. Please try > downgrading to the previous versions of harfbuzz and freetype2 and see if that > fixes the problem. That did fix the problem! I downgraded

Re: Apache Fork Errors - Found on Windows Server 2019

On 2021-10-17 09:54, Ken Brown via Cygwin wrote: On 10/16/2021 9:49 PM, OwN-3m-All via Cygwin wrote: Hopefully I can strace at some point soon and get back to you with the results. I have multiple confirmed reports from other people that this no longer works though.  And again, I tried it on th

Re: Apache Fork Errors - Found on Windows Server 2019

On 10/16/2021 9:49 PM, OwN-3m-All via Cygwin wrote: Hopefully I can strace at some point soon and get back to you with the results. I have multiple confirmed reports from other people that this no longer works though. And again, I tried it on three different fresh installs of different Windows

Re: Apache Fork Errors - Found on Windows Server 2019

Greetings, OwN-3m-All! > I can't seem to get apache via cygwin to work on Windows Server 2019. My question is tangential to Cygwin: why can't you run native Apache with native PHP? What Cygwin specific is in your needs? > Any idea why this is happening or how to fix it? cygcheck may provide a

Re: Apache Fork Errors - Found on Windows Server 2019

Hopefully I can strace at some point soon and get back to you with the results. I have multiple confirmed reports from other people that this no longer works though. And again, I tried it on three different fresh installs of different Windows operating systems (with no bloatware or BLODA), and al

Re: Apache Fork Errors - Found on Windows Server 2019

On 10/15/2021 4:04 PM, OwN-3m-All via Cygwin wrote: Downgrading (choosing lower versions) httpd and httpd-mod_php7 didn't help. Same issue. It appears to be something cygwin specific and not package related? I don't know... Running the httpd command under strace might provide a clue. See if

Re: Apache Fork Errors - Found on Windows Server 2019

Downgrading (choosing lower versions) httpd and httpd-mod_php7 didn't help. Same issue. It appears to be something cygwin specific and not package related? I don't know... -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:

Re: Apache Fork Errors - Found on Windows Server 2019

I checked, and I'm not running anything listed here: https://cygwin.com/faq/faq.html#faq.using.bloda I even disabled Windows Defender to see if that would make a difference, but it didn't. Results in a fresh install of Windows 10 Pro N 21H1 19043.928 are similar: 1 [main] httpd 1879 child

Re: Apache Fork Errors - Found on Windows Server 2019

> I suggest you disable whatever BLODA Such as? This is a fresh install of Windows Server 2019 with no additional apps installed. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscrib

Re: Apache Fork Errors - Found on Windows Server 2019

OwN-3m-All via Cygwin writes: […] > \??\C:\OGP64\bin\cygharfbuzz-0.dll: Loaded to different address: > parent(0x3FE6C) != child(0x60) > [Thu Oct 14 20:35:18.358045 2021] [mpm_prefork:error] [pid 89] (11)Resource > temporarily unavailable: AH00159: fork: Unable to fork new process > 0

Re: Apache Fork Errors - Found on Windows Server 2019

> Apache had/has two run modes, pre-forking and threaded. It appears you're running it in pre-forking mode. Try running it in threaded mode. This might be controlled by httpd.conf or some other Apache config file. That is doable, but changing it makes it so that PHP no longer works. To make tha

Re: Apache Fork Errors - Found on Windows Server 2019

Hi, OwN-3m-All via Cygwin wrote: Hi All, I can't seem to get apache via cygwin to work on Windows Server 2019. Here is my error log: 0 [main] httpd 1360 child_info_fork::abort: \??\C:\OGP64\bin\cygharfbuzz-0.dll: Loaded to different address: parent(0x3FAF6) != child(0xCD) [Thu

Apache Fork Errors - Found on Windows Server 2019

Hi All, I can't seem to get apache via cygwin to work on Windows Server 2019. Here is my error log: 0 [main] httpd 1360 child_info_fork::abort: \??\C:\OGP64\bin\cygharfbuzz-0.dll: Loaded to different address: parent(0x3FAF6) != child(0xCD) [Thu Oct 14 20:21:24.306514 2021] [mpm_pre

Re: fork errors

To clarify, I don't see the fork errors in the Son-Of-Grid Engine (SOGE) process. Separately, we have a script that connects to the box via ssh under cygwin and runs a lot of Make, bash and perl scripts and calls Windows executables. It's these scripts that are giving the fork errors.

Re: fork errors

Jurgen, No anti-virus at all on this machine. The daemon is Son-of-Grid Engine execd. It waits for instructions to run scripts from the qmaster. Simon On Tue, Apr 3, 2018 at 2:12 PM, Jürgen Wagner wrote: > Simon, > chances are this has nothing to do with rebasing but rather with the > anti-

Re: fork errors

- Original Message - > From: Simon Matthews  > To: cygwin > Cc: > Date: 2018/4/4, Wed 00:20 > Subject: fork errors > > I have been seeing a large number of error messages like this: > 2 [main] bash 8652 fork: child -1 - forked process 7532 died > unexp

Re: fork errors

Simon,   chances are this has nothing to do with rebasing but rather with the anti-virus product on your system. Do you happen to use Comodo CIS? Without proper configuration, Cygwin will show such fork fails in some situations. Cheers, --J. On 03/04/2018 17:20, Simon Matthews wrote: >> I have be

Re: fork errors

On 03/04/2018 17:20, Simon Matthews wrote: I have been seeing a large number of error messages like this: 2 [main] bash 8652 fork: child -1 - forked process 7532 died unexpectedly, retry 0, exit code 0xC005, errno 11 2 [main] bash 8652 fork: child -1 - forked process 7532 died unexpectedly, r

fork errors

I have been seeing a large number of error messages like this: 2 [main] bash 8652 fork: child -1 - forked process 7532 died unexpectedly, retry 0, exit code 0xC005, errno 11 2 [main] bash 8652 fork: child -1 - forked process 7532 died unexpectedly, retry 0, exit code 0xC005, errno 11 I fol

Re: Cygwin 2.6.1 bash fork errors upon starting mintty

created a cygcheck -s -r -v file to attach, but sourceware dot org >> blocked it > > Sourceware blocks all non-text emails - see below. > >> Updated Cygwin this morning, getting fork errors (even after >> rebooting, (although reboots should not matter)) when starting &g

Re: Cygwin 2.6.1 bash fork errors upon starting mintty

On 2016-12-26 09:19, Keith Christian wrote: > I created a cygcheck -s -r -v file to attach, but sourceware dot org > blocked it Sourceware blocks all non-text emails - see below. > Updated Cygwin this morning, getting fork errors (even after > rebooting, (although reboots shoul

Cygwin 2.6.1 bash fork errors upon starting mintty

I created a cygcheck -s -r -v file to attach, but sourceware dot org blocked it Updated Cygwin this morning, getting fork errors (even after rebooting, (although reboots should not matter)) when starting mintty: 0 [main] bash 6072 child_info_fork::abort: C:\cygwin\bin\cygncursesw-10.dll

Re: Fork errors in python2.7 on 64-bit Cygwin

Greetings, Michael Wild! >>> * Trying to run a shell command from Python fails 50% of the time >>> with: address space needed by 'cygz.dll' (0x45) is already >>> occupied. >> >> Such a low address on 64bit is an indication of an image intercept >> and/or BLODA in my experience. >> > Thanks fo

Re: Fork errors in python2.7 on 64-bit Cygwin

On Sun, Feb 1, 2015 at 3:06 PM, Achim Gratz wrote: > Michael Wild writes: >> * Trying to run a shell command from Python fails 50% of the time >> with: address space needed by 'cygz.dll' (0x45) is already >> occupied. > > Such a low address on 64bit is an indication of an image intercept > and/

Re: Fork errors in python2.7 on 64-bit Cygwin

Michael Wild writes: > * Trying to run a shell command from Python fails 50% of the time > with: address space needed by 'cygz.dll' (0x45) is already > occupied. Such a low address on 64bit is an indication of an image intercept and/or BLODA in my experience. > * rebase -si only shows an aste

Fork errors in python2.7 on 64-bit Cygwin

Dear all I know, this is topic everybody is fed up with and that it has been discussed ad nauseum. Still, I can't figure out what's going on... Here the symptoms: * Trying to run a shell command from Python fails 50% of the time with: address space needed by 'cygz.dll' (0x45) is already occup

Re: using spawn functions to avoid fork() errors -- FIXED

Greetings, Steven Bardwell! > I found the problem that was causing the failure of child creation logic > on the 64-bit install but not on the 32-bit version: > in an effort to make the output from 'ps' more useful, my application was > over-writing the contents of argv[1] in the main process. Th

RE: using spawn functions to avoid fork() errors -- FIXED

> >> On 2/6/2014 8:50 AM, Steven Bardwell wrote: > >>> Larry - thanks for the link to the source for the spawn() APIs. It > > works > >>> perfectly on my 32-bit install (where, as it happens, the fork() issue > >>> never shows up either). > >>> > >>> However, on my 64-bit install, the spawnv() cal

RE: using spawn functions to avoid fork() errors -- FIXED

> >> On 2/6/2014 8:50 AM, Steven Bardwell wrote: > >>> Larry - thanks for the link to the source for the spawn() APIs. It > > works > >>> perfectly on my 32-bit install (where, as it happens, the fork() issue > >>> never shows up either). > >>> > >>> However, on my 64-bit install, the spawnv() cal

Re: using spawn functions to avoid fork() errors

>>> On 2/6/2014 8:50 AM, Steven Bardwell wrote: However, on my 64-bit install, the spawnv() call is returning with an error -- 'No such file or directory' -- when I try to spawn /bin/sh. A few things come to mind as possibilities to check, or try. First, there is a certain amount of mag

Re: using spawn functions to avoid fork() errors

On 2/6/2014 5:14 PM, Steven Bardwell wrote: On 2/6/2014 8:50 AM, Steven Bardwell wrote: Larry - thanks for the link to the source for the spawn() APIs. It works perfectly on my 32-bit install (where, as it happens, the fork() issue never shows up either). However, on my 64-bit install, the

RE: using spawn functions to avoid fork() errors

> On 2/6/2014 8:50 AM, Steven Bardwell wrote: > > Larry - thanks for the link to the source for the spawn() APIs. It works > > perfectly on my 32-bit install (where, as it happens, the fork() issue > > never shows up either). > > > > However, on my 64-bit install, the spawnv() call is returning w

Re: using spawn functions to avoid fork() errors

On 2/6/2014 8:50 AM, Steven Bardwell wrote: On 2/5/2014 7:07 AM, Steven Bardwell wrote: I have no problem doing some recoding of my application to reliably solve my issues with fork() -- can you all point me in the direction of the 'spawn family of calls'? See spawn.cc ->

Re: using spawn functions to avoid fork() errors

On 2/5/2014 7:07 AM, Steven Bardwell wrote: From reading the Cygwin FAQ ("In most cases, you are better off using the spawn family of calls if possible.") and the Cygwin Highlights ("Fortunately, in most circumstances the spawn family of calls provided by Cygwin can be substituted for a fork/exe

Re: Fork errors during toolchain build

On 3/15/2012 8:20 PM, Ryan Johnson wrote: Hi all, I'm trying to build a crosstool chain under cygwin and I keep getting blocked by fork errors -- in spite of having rebased just before starting. Oddly, the errors come from scripts, not invocations of just-built-gcc (which used to be the k

Fork errors during toolchain build

Hi all, I'm trying to build a crosstool chain under cygwin and I keep getting blocked by fork errors -- in spite of having rebased just before starting. Oddly, the errors come from scripts, not invocations of just-built-gcc (which used to be the killer). Unfortunately, this means there

Re: extremely rarely fork errors: who occuppies the space?

On Feb 6 11:56, Heiko Elger wrote: > Corinna Vinschen writes: > > Just use peflags to remove the flag instead of reinstalling. I'm not > > sure if some DLLs have this flag set by default in the distro, and in > > that case you're back to square one and have to run peflags anyway. > > That's why

Re: extremely rarely fork errors: who occuppies the space?

Corinna Vinschen writes: > > On Feb 6 11:00, Heiko Elger wrote: > > Corinna Vinschen writes: > > > > > > > > > > Antivirus software is deinstalled, Windows defender is deactivated. > > > > Rebaseall and peflagsall were running. > > > > > > YoU don't need to run peflags. If you have set the A

Re: extremely rarely fork errors: who occuppies the space?

On Feb 6 11:00, Heiko Elger wrote: > Corinna Vinschen writes: > > > > > > > Antivirus software is deinstalled, Windows defender is deactivated. > > > Rebaseall and peflagsall were running. > > > > YoU don't need to run peflags. If you have set the ASLR flag, it could > > be the culprit. Try r

Re: extremely rarely fork errors: who occuppies the space?

Corinna Vinschen writes: > > > > Antivirus software is deinstalled, Windows defender is deactivated. > > Rebaseall and peflagsall were running. > > YoU don't need to run peflags. If you have set the ASLR flag, it could > be the culprit. Try resetting it and, I think, reboot the machine. As >

Re: extremely rarely fork errors: who occuppies the space?

> uname -a > CYGWIN_NT-6.1-WOW64 PCFX061 1.7.10s(0.259/5/3) 20120202 16:59:00 i686 Cygwin > > We've still some not reproduceable fork errors like the following > 0 [main] sh 90024 child_info_fork::abort: address space needed > by 'cygiconv-2.dll' (0x6D0D) i

extremely rarely fork errors: who occuppies the space?

Cygwin We've still some not reproduceable fork errors like the following 0 [main] sh 90024 child_info_fork::abort: address space needed by 'cygiconv-2.dll' (0x6D0D) is already occupied 7 [main] sh 88036 child_info_fork::abort: address space needed by 'cygiconv-2.

Re: help for diagnose unpedictable "fork errors", "cygheap base msimatch errors"

On 17/11/2011 12:36 AM, Heiko Elger wrote: marco atzeri Heiko, you wrote a lot of mail , but I do not remember a single Problem reports: http://cygwin.com/problems.html As cygwin is working on win7/64, something is wrong on your machine, but until you provide clear data we can not easly h

Re: help for diagnose unpedictable "fork errors", "cygheap base msimatch errors"

marco atzeri > Heiko, > you wrote a lot of mail , but I do not remember a single > > Problem reports: http://cygwin.com/problems.html > > As cygwin is working on win7/64, something is wrong on your machine, > but until you provide clear data we can not easly help you. > > I am currently

Re: help for diagnose unpedictable "fork errors", "cygheap base msimatch errors"

On 11/16/2011 1:40 PM, Heiko Elger wrote: Hello, we've still cygwin system errors. I use snapshot 20111030 and all other colleagues snapshot 20110829. We've done rebaseall and peflagsall. We have win7/64 (CYGWIN_NT-6.1-WOW64). All errors are unpredictable - so there is really no possible testca

help for diagnose unpedictable "fork errors", "cygheap base msimatch errors"

Hello, we've still cygwin system errors. I use snapshot 20111030 and all other colleagues snapshot 20110829. We've done rebaseall and peflagsall. We have win7/64 (CYGWIN_NT-6.1-WOW64). All errors are unpredictable - so there is really no possible testcase. I noticed the following problems: 1. ru

Re: how to log "fork errors", cygheap errors with syslogd

On Nov 16 08:07, Heiko Elger wrote: > Hello, > > I'm sorry - but cause of sometimes having unpredictable and unreproduceable > cygwin errors like "fork error, cygheap check", I trieded to run syslogd to > log these all these errors in /var/log/messages. > > But these kind of errors are not logg

how to log "fork errors", cygheap errors with syslogd

Hello, I'm sorry - but cause of sometimes having unpredictable and unreproduceable cygwin errors like "fork error, cygheap check", I trieded to run syslogd to log these all these errors in /var/log/messages. But these kind of errors are not logged there. How do I have to configure my syslogd -

Re: 1.7 fork errors in Win7

3:29 PM,  Eliot Moss, wrote >> >> Date: Wed, 02 Dec 2009 11:43:44 -0500 >> Subject: Re: 1.7 fork errors in Win7 >> Luis P Caamano wrote: >>> >>> I'm running 1.7.0-67 on Windows 7 64 bit: >>> >>> $ uname -v >>> 2009-11-27 15:38 &

Re: 1.7 fork errors in Win7

Luis P Caamano wrote: Thanks Eliot, I'll try that later tonight and I'll report back. I'm also getting this kind of error from gvim (that I built myself to add python to it): 2 [main] vim 7580 C:\cygwin\usr\local\bin\vim.exe: *** fatal error - unable to remap \\?\C:\cygwin\lib\gtk-2.0\2.1

Re: 1.7 fork errors in Win7

On Wed, Dec 2, 2009 at 3:29 PM, Eliot Moss, wrote > > Date: Wed, 02 Dec 2009 11:43:44 -0500 > Subject: Re: 1.7 fork errors in Win7 > Luis P Caamano wrote: >> >> I'm running 1.7.0-67 on Windows 7 64 bit: >> >> $ uname -v >> 2009-11-27 15:38 >>

Re: 1.7 fork errors in Win7

Luis P Caamano wrote: I'm running 1.7.0-67 on Windows 7 64 bit: $ uname -v 2009-11-27 15:38 and I'm getting sporadic for errors like this one: $ svn commit -m "xxx yyy" 2 [main] svn 5924 fork: child -1 - died waiting for longjmp before initialization, retry 0, exit code 0xC005, errno

1.7 fork errors in Win7

I'm running 1.7.0-67 on Windows 7 64 bit: $ uname -v 2009-11-27 15:38 and I'm getting sporadic for errors like this one: $ svn commit -m "xxx yyy" 2 [main] svn 5924 fork: child -1 - died waiting for longjmp before initialization, retry 0, exit code 0xC005, errno 11 svn: Commit failed (

Re: perl fork errors with a cygwin dll?

[EMAIL PROTECTED] wrote: This happens about 50% of the time when I run some kind of fork from perl in cygwin: Executing: rsync -a --delete --delete-excluded --stats -v --progress '/cygdrive/d/coLinux' '/cygdrive/h/Backup/coLinux' 9648 [main] perl 4064 d:\cygwin\bin\perl.exe: *** fatal error -

Re: perl fork errors with a cygwin dll?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to [EMAIL PROTECTED] on 3/22/2007 11:26 PM: > This happens about 50% of the time when I run some kind of fork from > perl in cygwin: > > Executing: rsync -a --delete --delete-excluded --stats -v --progress > '/cygdrive/d/coLinux' '/cygdrive/

perl fork errors with a cygwin dll?

This happens about 50% of the time when I run some kind of fork from perl in cygwin: Executing: rsync -a --delete --delete-excluded --stats -v --progress '/cygdrive/d/coLinux' '/cygdrive/h/Backup/coLinux' 9648 [main] perl 4064 d:\cygwin\bin\perl.exe: *** fatal error - unable to remap d:\cygwin

fork errors - search snips from cygwin mailing list archive

in a datacenter; anti-virus scanning is *not* real time, but scheduled weekly. The attachment is output from: msinfo32 /report FILENAMEHERE /catagory systemsummary msinfo32.out.gz Description: msinfo32 /report FILENAMEHERE /catagory systemsummary For us, in general the fork errors do not show u

Re: fairly repeatable fork(?) errors in (contrived) test script

On Wed 9/21/05 11:44 EDT (cgf) cygwin@cygwin.com wrote: > On Wed, Sep 21, 2005 at 09:13:09AM -0500, Tom Rodman wrote: > >All: > > > >I'm using the 9/19 snapshot. The sleep in the below test script seems to > >be required, otherwise the script could be simplified and still > >cause errors. Today I

Re: fairly repeatable fork(?) errors in (contrived) test script

On Wed, Sep 21, 2005 at 09:13:09AM -0500, Tom Rodman wrote: >All: > >I'm using the 9/19 snapshot. The sleep in the below test script seems to >be required, otherwise the script could be simplified and still >cause errors. > >The test script works (always?) without errors on 1.3.20. 1.3.20? That i

fairly repeatable fork(?) errors in (contrived) test script

All: I'm using the 9/19 snapshot. The sleep in the below test script seems to be required, otherwise the script could be simplified and still cause errors. The test script works (always?) without errors on 1.3.20. Here are a couple of test runs: ~ $ /tmp/test x: 1 x: 2 x: 3 x: 4 x: