-
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've been
> -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
> -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
> -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:
> >
> > S
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
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 =
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 script
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 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 that.
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 some
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:
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
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
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
> 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
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
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
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
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
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
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:
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
> 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
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
> 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
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
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]
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. The intent
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
- 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
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
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,
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
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 s
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
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
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
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
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/or BLODA
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 for your answer.
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 with an
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 with an
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. This
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 -
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 with an
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,
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 magic that
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/exec
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 killer
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's
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) is already occupied
7 [main] sh 88036 child_info_fork::abort: address
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
far as I
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 resetting it and,
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 ASLR flag, it could
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 I did
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.dll' (0x6D0D
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 -
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 logged
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.
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
marco atzeri marco.atzeri writes:
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
On 17/11/2011 12:36 AM, Heiko Elger wrote:
marco atzerimarco.atzeri writes:
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
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
and I'm getting sporadic for errors like this one:
$ svn commit -m xxx yyy
2 [main] svn 5924 fork: child -1 - died
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
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
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
and I'm getting sporadic for errors like this one:
$ svn commit -m
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
-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'
[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
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
; 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 up until quite
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 carefully
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:
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 is at
74 matches
Mail list logo