Re: EXTERNAL SENDER: Re: Fork errors

[Mark Geisert via Cygwin]

Hi Dale,
Something appears to be adding cruft to your outgoing emails.. links to 
urldefense.com that don't work (from outside your workplace maybe) and clutter up 
the Cygwin email archives.  Can you turn that off somehow?  More below...


Dale Lobb via Cygwin wrote:

-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 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 temporary directories, but never in the same place in the script.  The
script uses multiple calls to find -exec to remove files over 10 days old from
the directories.  Here is a typical error.  Sometime the issue will assert after
just a  few tens of files deleted, sometimes after hundreds or thousands of
files have been deleted:


  removed '/cygdrive/d/.../obfuscated.datedata.txt'
1 [main] find 20066 dofork: child -1 - forked process 4068 died

unexpectedly, retry 0, exit code 0xC142, errno 11

find: cannot fork: Resource temporarily unavailable

It also happens randomly at other times.  I've seen the bash shell itself 
fail

on the invocation of a mintty.  I've seen it happen on all sorts of interactive
commands entered from bash.


Today, as a test, I updated all the installed Cygwin components.  One of

the post installation scripts failed, so I re-exec'd it:


  $ ./postinstall/0p_update-info-dir.dash
  Rebuilding info directory
  2 [main] dash 2059 dofork: child -1 - forked process 7676 died

unexpectedly, retry 0, exit code 0xC142, errno 11

  ./postinstall/0p_update-info-dir.dash: 22: Cannot fork

A second re-exec then worked fine.

I've tried reinstalling all the components, and I've tried rebaseall.

Is there anything else I can try, or troubleshooting steps to take?


Try the FAQ, specifically
https://urldefense.com/v3/__https://cygwin.com/faq.html*faq.using.fixing-
fork-
failures__;Iw!!PI4dZuVR!iMEVdwUomDN3L1KOsOWkDMmUhiuXarkAyjI6itT-
BSJ5bcjg65VVWHdP7U5Ny2VaBilIz9R3o6SkMqX3$


Example #1 of added cruft above.  Something appears to be rewriting URLs for 
"safety".



Pay attention to the subtleties of running rebaseall, e.g. make sure no Cygwin
processes (background server processes or whatnot) are running.  When the
FAQ gets
to talking about running setup.exe for this situation, it means close any open
Cygwin shell windows and manually run the Cygwin Setup program, just
taking its
defaults all the way through; you needn't install anything it suggests at this
time.  The object is to get to Setup's end where it runs a full rebase.

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.


As corrected by another poster, it's hex 142 == decimal 322 == 
ERROR_DEVICE_NO_RESOURCES.




..mark




CONFIDENTIALITY NOTICE: This e-mail message, including any attachments,

is for the sole use of the intended recipients and may contain confidential
and privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message.

P.S. You've sent your post to a public mailing list so the above notice does not
apply.  Obfuscate your system particulars if that's a problem.


Can you eliminate this confidentiality notice from your emails to the Cygwin 
mailing list?




--
Problem reports:
https://urldefense.com/v3/__https://cygwin.com/problems.html__;!!PI4dZu
VR!iMEVdwUomDN3L1KOsOWkDMmUhiuXarkAyjI6itT-
BSJ5bcjg65VVWHdP7U5Ny2VaBilIz9R3o_fDJhhS$
FAQ:
https://urldefense.com/v3/__https://cygwin.com/faq/__;!!PI4dZuVR!iMEVd
wUomDN3L1KOsOWkDMmUhiuXarkAyjI6itT-
BSJ5bcjg65VVWHdP7U5Ny2VaBilIz9R3o5GKnVUD$
Documentation:
https://urldefense.com/v3/__https://cygwin.com/docs.html__;!!PI4dZuVR!i
MEVdwUomDN3L1KOsOWkDMmUhiuXarkAyjI6itT-
BSJ5bcjg65VVWHdP7U5Ny2VaBilIz9R3o2A6MIc4$
Unsubscribe info:
https://urldefense.com/v3/__https://cygwin.com/ml/*unsubscribe-
simple__;Iw!!PI4dZuVR!iMEVdwUomDN3L1KOsOWkDMmUhiuXarkAyjI6itT-
BSJ5bcjg65VVWHdP7U5Ny2VaBilIz9R3o4OJCuT7$


Examples #2-#5 of added cruft above.


Hi Mark, thanks for the reply!

   I ran though the rebase-trigger process as outlined in the FAQ.
Unfortunately,  there was no difference afterwards.

   One good thing about reading the FAQ, it lead me to
"/usr/share/doc/rebase/README" which has the parameters for the
rebaseall command.  I'm thinking about running rebaseall manually with a
different base addr

RE: EXTERNAL SENDER: Re: Fork errors

[Dale Lobb via Cygwin]

> -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 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 temporary directories, but never in the same place in the script.  The
> script uses multiple calls to find -exec to remove files over 10 days old from
> the directories.  Here is a typical error.  Sometime the issue will assert 
> after
> just a  few tens of files deleted, sometimes after hundreds or thousands of
> files have been deleted:
> >
> >  removed '/cygdrive/d/.../obfuscated.datedata.txt'
> >1 [main] find 20066 dofork: child -1 - forked process 4068 died
> unexpectedly, retry 0, exit code 0xC142, errno 11
> >find: cannot fork: Resource temporarily unavailable
> >
> >It also happens randomly at other times.  I've seen the bash shell 
> > itself fail
> on the invocation of a mintty.  I've seen it happen on all sorts of 
> interactive
> commands entered from bash.
> >
> >Today, as a test, I updated all the installed Cygwin components.  One of
> the post installation scripts failed, so I re-exec'd it:
> >
> >  $ ./postinstall/0p_update-info-dir.dash
> >  Rebuilding info directory
> >  2 [main] dash 2059 dofork: child -1 - forked process 7676 died
> unexpectedly, retry 0, exit code 0xC142, errno 11
> >  ./postinstall/0p_update-info-dir.dash: 22: Cannot fork
> >
> >A second re-exec then worked fine.
> >
> >I've tried reinstalling all the components, and I've tried rebaseall.
> >
> >Is there anything else I can try, or troubleshooting steps to take?
>
> Try the FAQ, specifically
> https://urldefense.com/v3/__https://cygwin.com/faq.html*faq.using.fixing-
> fork-
> failures__;Iw!!PI4dZuVR!iMEVdwUomDN3L1KOsOWkDMmUhiuXarkAyjI6itT-
> BSJ5bcjg65VVWHdP7U5Ny2VaBilIz9R3o6SkMqX3$
>
> Pay attention to the subtleties of running rebaseall, e.g. make sure no Cygwin
> processes (background server processes or whatnot) are running.  When the
> FAQ gets
> to talking about running setup.exe for this situation, it means close any open
> Cygwin shell windows and manually run the Cygwin Setup program, just
> taking its
> defaults all the way through; you needn't install anything it suggests at this
> time.  The object is to get to Setup's end where it runs a full rebase.
>
> 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.
>
> ..mark
>
> > 
> >
> > CONFIDENTIALITY NOTICE: This e-mail message, including any attachments,
> is for the sole use of the intended recipients and may contain confidential
> and privileged information. Any unauthorized review, use, disclosure or
> distribution is prohibited. If you are not the intended recipient, please
> contact the sender by reply e-mail and destroy all copies of the original
> message.
>
> P.S. You've sent your post to a public mailing list so the above notice does 
> not
> apply.  Obfuscate your system particulars if that's a problem.
>
> --
> Problem reports:
> https://urldefense.com/v3/__https://cygwin.com/problems.html__;!!PI4dZu
> VR!iMEVdwUomDN3L1KOsOWkDMmUhiuXarkAyjI6itT-
> BSJ5bcjg65VVWHdP7U5Ny2VaBilIz9R3o_fDJhhS$
> FAQ:
> https://urldefense.com/v3/__https://cygwin.com/faq/__;!!PI4dZuVR!iMEVd
> wUomDN3L1KOsOWkDMmUhiuXarkAyjI6itT-
> BSJ5bcjg65VVWHdP7U5Ny2VaBilIz9R3o5GKnVUD$
> Documentation:
> https://urldefense.com/v3/__https://cygwin.com/docs.html__;!!PI4dZuVR!i
> MEVdwUomDN3L1KOsOWkDMmUhiuXarkAyjI6itT-
> BSJ5bcjg65VVWHdP7U5Ny2VaBilIz9R3o2A6MIc4$
> Unsubscribe info:
> https://urldefense.com/v3/__https://cygwin.com/ml/*unsubscribe-
> simple__;Iw!!PI4dZuVR!iMEVdwUomDN3L1KOsOWkDMmUhiuXarkAyjI6itT-
> BSJ5bcjg65VVWHdP7U5Ny2VaBilIz9R3o4OJCuT7$

Hi Mark, thanks for the reply!

  I ran though the rebase-trigger process as outlined in the FAQ.
Unfortunately,  there was no difference afterwards.

  One good thing about reading the FAQ, it lead me to
"/usr/share/doc/rebase/README" which has the parameters for the
rebaseall command.  I'm thinking about running rebaseall manually with a
different base address than the default (0x7000

RE: EXTERNAL SENDER: RE: Fork errors

[Dale Lobb via Cygwin]

> -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 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.
> > > 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 temporary directories, but never in the same place in the
> > > script.  The script uses multiple calls to find -exec to remove files
> > > over 10 days old from the directories.  Here is a typical error.
> > > Sometime the issue will assert after just a  few tens of files
> > > deleted, sometimes after hundreds or thousands of files have been
> > > deleted:
> > >
> > > removed '/cygdrive/d/.../obfuscated.datedata.txt'
> > > 1 [main] find 20066 dofork: child -1 - forked process 4068 died
> > > unexpectedly, retry 0, exit code 0xC142, errno 11
> > > find: cannot fork: Resource temporarily unavailable
> > >
> > > It also happens randomly at other times.  I've seen the bash shell
> > > itself fail on the invocation of a mintty.  I've seen it happen on all
> > > sorts of interactive commands entered from bash.
> > >
> > > Today, as a test, I updated all the installed Cygwin components.
> > > One of the post installation scripts failed, so I re-exec'd it:
> > >
> > > $ ./postinstall/0p_update-info-dir.dash
> > > Rebuilding info directory
> > > 2 [main] dash 2059 dofork: child -1 - forked process 7676 died
> > > unexpectedly, retry 0, exit code 0xC142, errno 11
> > > ./postinstall/0p_update-info-dir.dash: 22: Cannot fork
> > >
> > > A second re-exec then worked fine.
> > >
> > > I've tried reinstalling all the components, and I've tried rebaseall.
> > >
> > > Is there anything else I can try, or troubleshooting steps to take?
> > >
> > > Best Regards,
> >
> > Take a look at this:
>
> Also, there are a bunch of hits on duckduckgo:
>
> https://duckduckgo.com/?q=++find%3A+cannot+fork%3A+Resource+temporarily+unavailable+cygwin=web
>
> 
>
> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments,
> is for the sole use of the intended recipients and may contain confidential
> and privileged information. Any unauthorized review, use, disclosure or
> distribution is prohibited. If you are not the intended recipient, please
> contact the sender by reply e-mail and destroy all copies of the original
> message.

  Yep, read through most of those already.  Many are from a very long time
ago, when Cygwin was still 32 bit and seem to have little utility in the 64 bit
world where ASLR is on in Windows by default for 64 bit images.

  Thanks, though!

Best Regards,

Dale Lobb





CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipients and may contain confidential and 
privileged information. Any unauthorized review, use, disclosure or 
distribution is prohibited. If you are not the intended recipient, please 
contact the sender by reply e-mail and destroy all copies of the original 
message.

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

RE: EXTERNAL SENDER: RE: Fork errors

[Dale Lobb via Cygwin]

> -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:
> >
> > 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 temporary directories, but never in the same place in the
> > script.  The script uses multiple calls to find -exec to remove
> > files over 10 days old from the directories.  Here is a typical
> > error.  Sometime the issue will assert after just a  few tens of
> > files deleted, sometimes after hundreds or thousands of files have
> > been deleted:
> >
> > removed '/cygdrive/d/.../obfuscated.datedata.txt'
> > 1 [main] find 20066 dofork: child -1 - forked process 4068 died
> > unexpectedly, retry 0, exit code 0xC142, errno 11
> > find: cannot fork: Resource temporarily unavailable
> >
> > It also happens randomly at other times.  I've seen the bash shell
> > itself fail on the invocation of a mintty.  I've seen it happen on
> > all sorts of interactive commands entered from bash.
> >
> > Today, as a test, I updated all the installed Cygwin components.
> > One of the post installation scripts failed, so I re-exec'd it:
> >
> > $ ./postinstall/0p_update-info-dir.dash
> > Rebuilding info directory
> > 2 [main] dash 2059 dofork: child -1 - forked process 7676 died
> > unexpectedly, retry 0, exit code 0xC142, errno 11
> > ./postinstall/0p_update-info-dir.dash: 22: Cannot fork
> >
> > A second re-exec then worked fine.
> >
> > I've tried reinstalling all the components, and I've tried
> > rebaseall.
> >
> > Is there anything else I can try, or troubleshooting steps to
> > take?
> >
> > Best Regards,
>
> Take a look at this:
>
> https://stackoverflow.com/questions/36399041/cygwin-update-cause-error-could-not-fork-child-process-resource-temporarily-u
>
> it may not help, but it's something to look into.
>
> 
>
> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments,
> is for the sole use of the intended recipients and may contain confidential
> and privileged information. Any unauthorized review, use, disclosure or
> distribution is prohibited. If you are not the intended recipient, please
> contact the sender by reply e-mail and destroy all copies of the original
> message.


Hello Jose,

  Thank you for the reply.

  I read through the Stack Overflow post.  Unfortunately, Windows Server
2016 is based on an early version of Windows 10, which does not have the
"Windows Defender Security Center" app.  Only 2019 and later versions have
that feature.

  I did find this article and used the group policy editor to disable ASLR for
several Cygwin executables (ash, bash, find, rm), but that didn't make any
difference.

https://learn.microsoft.com/en-us/windows/security/threat-protection/override-mitigation-options-for-app-related-security-policies

Best Regards,

Dale Lobb





CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipients and may contain confidential and 
privileged information. Any unauthorized review, use, disclosure or 
distribution is prohibited. If you are not the intended recipient, please 
contact the sender by reply e-mail and destroy all copies of the original 
message.

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Fork errors

[Mark Geisert via Cygwin]

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 142 = decimal 322 =
ERROR_DEVICE_NO_RESOURCES ("The target device has insufficient resources to
complete the operation").


D'oh! Tnx for correction.

..mark

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Fork errors

[Bill Stewart via Cygwin]

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_DEVICE_NO_RESOURCES ("The target device has insufficient resources to
complete the operation").

Bill

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Fork errors

[Mark Geisert via Cygwin]

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 is invoked that purges files from some 
temporary directories, but never in the same place in the script.  The script 
uses multiple calls to find -exec to remove files over 10 days old from the 
directories.  Here is a typical error.  Sometime the issue will assert after 
just a  few tens of files deleted, sometimes after hundreds or thousands of 
files have been deleted:

 removed '/cygdrive/d/.../obfuscated.datedata.txt'
   1 [main] find 20066 dofork: child -1 - forked process 4068 died 
unexpectedly, retry 0, exit code 0xC142, errno 11
   find: cannot fork: Resource temporarily unavailable

   It also happens randomly at other times.  I've seen the bash shell itself 
fail on the invocation of a mintty.  I've seen it happen on all sorts of 
interactive commands entered from bash.

   Today, as a test, I updated all the installed Cygwin components.  One of the 
post installation scripts failed, so I re-exec'd it:

 $ ./postinstall/0p_update-info-dir.dash
 Rebuilding info directory
 2 [main] dash 2059 dofork: child -1 - forked process 7676 died 
unexpectedly, retry 0, exit code 0xC142, errno 11
 ./postinstall/0p_update-info-dir.dash: 22: Cannot fork

   A second re-exec then worked fine.

   I've tried reinstalling all the components, and I've tried rebaseall.

   Is there anything else I can try, or troubleshooting steps to take?


Try the FAQ, specifically
https://cygwin.com/faq.html#faq.using.fixing-fork-failures

Pay attention to the subtleties of running rebaseall, e.g. make sure no Cygwin 
processes (background server processes or whatnot) are running.  When the FAQ gets 
to talking about running setup.exe for this situation, it means close any open 
Cygwin shell windows and manually run the Cygwin Setup program, just taking its 
defaults all the way through; you needn't install anything it suggests at this 
time.  The object is to get to Setup's end where it runs a full rebase.


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.


..mark




CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipients and may contain confidential and 
privileged information. Any unauthorized review, use, disclosure or 
distribution is prohibited. If you are not the intended recipient, please 
contact the sender by reply e-mail and destroy all copies of the original 
message.


P.S. You've sent your post to a public mailing list so the above notice does not 
apply.  Obfuscate your system particulars if that's a problem.


--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

RE: Fork errors

[Jose Isaias Cabrera via Cygwin]

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.
> > 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 temporary directories, but never in the same place in the
> > script.  The script uses multiple calls to find -exec to remove files
> > over 10 days old from the directories.  Here is a typical error.
> > Sometime the issue will assert after just a  few tens of files
> > deleted, sometimes after hundreds or thousands of files have been
> > deleted:
> >
> > removed '/cygdrive/d/.../obfuscated.datedata.txt'
> > 1 [main] find 20066 dofork: child -1 - forked process 4068 died
> > unexpectedly, retry 0, exit code 0xC142, errno 11
> > find: cannot fork: Resource temporarily unavailable
> >
> > It also happens randomly at other times.  I've seen the bash shell
> > itself fail on the invocation of a mintty.  I've seen it happen on all
> > sorts of interactive commands entered from bash.
> >
> > Today, as a test, I updated all the installed Cygwin components.
> > One of the post installation scripts failed, so I re-exec'd it:
> >
> > $ ./postinstall/0p_update-info-dir.dash
> > Rebuilding info directory
> > 2 [main] dash 2059 dofork: child -1 - forked process 7676 died
> > unexpectedly, retry 0, exit code 0xC142, errno 11
> > ./postinstall/0p_update-info-dir.dash: 22: Cannot fork
> >
> > A second re-exec then worked fine.
> >
> > I've tried reinstalling all the components, and I've tried rebaseall.
> >
> > Is there anything else I can try, or troubleshooting steps to take?
> >
> > Best Regards,
> 
> Take a look at this:

Also, there are a bunch of hits on duckduckgo:

https://duckduckgo.com/?q=++find%3A+cannot+fork%3A+Resource+temporarily+unavailable+cygwin

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

RE: Fork errors

[Jose Isaias Cabrera via Cygwin]

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.
> 
> The issue happens every time a script is invoked that purges files
> from some temporary directories, but never in the same place in the
> script.  The script uses multiple calls to find -exec to remove
> files over 10 days old from the directories.  Here is a typical
> error.  Sometime the issue will assert after just a  few tens of
> files deleted, sometimes after hundreds or thousands of files have
> been deleted:
> 
> removed '/cygdrive/d/.../obfuscated.datedata.txt'
> 1 [main] find 20066 dofork: child -1 - forked process 4068 died
> unexpectedly, retry 0, exit code 0xC142, errno 11
> find: cannot fork: Resource temporarily unavailable
> 
> It also happens randomly at other times.  I've seen the bash shell
> itself fail on the invocation of a mintty.  I've seen it happen on
> all sorts of interactive commands entered from bash.
> 
> Today, as a test, I updated all the installed Cygwin components. 
> One of the post installation scripts failed, so I re-exec'd it:
> 
> $ ./postinstall/0p_update-info-dir.dash
> Rebuilding info directory
> 2 [main] dash 2059 dofork: child -1 - forked process 7676 died
> unexpectedly, retry 0, exit code 0xC142, errno 11
> ./postinstall/0p_update-info-dir.dash: 22: Cannot fork
> 
> A second re-exec then worked fine.
> 
> I've tried reinstalling all the components, and I've tried
> rebaseall.
> 
> Is there anything else I can try, or troubleshooting steps to
> take?
> 
> Best Regards,

Take a look at this:

https://stackoverflow.com/questions/36399041/cygwin-update-cause-error-could-not-fork-child-process-resource-temporarily-u

it may not help, but it's something to look into.

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Fork errors

[Dale Lobb via Cygwin]

  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 
temporary directories, but never in the same place in the script.  The script 
uses multiple calls to find -exec to remove files over 10 days old from the 
directories.  Here is a typical error.  Sometime the issue will assert after 
just a  few tens of files deleted, sometimes after hundreds or thousands of 
files have been deleted:

removed '/cygdrive/d/.../obfuscated.datedata.txt'
  1 [main] find 20066 dofork: child -1 - forked process 4068 died 
unexpectedly, retry 0, exit code 0xC142, errno 11
  find: cannot fork: Resource temporarily unavailable

  It also happens randomly at other times.  I've seen the bash shell itself 
fail on the invocation of a mintty.  I've seen it happen on all sorts of 
interactive commands entered from bash.

  Today, as a test, I updated all the installed Cygwin components.  One of the 
post installation scripts failed, so I re-exec'd it:

$ ./postinstall/0p_update-info-dir.dash
Rebuilding info directory
2 [main] dash 2059 dofork: child -1 - forked process 7676 died 
unexpectedly, retry 0, exit code 0xC142, errno 11
./postinstall/0p_update-info-dir.dash: 22: Cannot fork

  A second re-exec then worked fine.

  I've tried reinstalling all the components, and I've tried rebaseall.

  Is there anything else I can try, or troubleshooting steps to take?

Best Regards,

Dale





CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipients and may contain confidential and 
privileged information. Any unauthorized review, use, disclosure or 
distribution is prohibited. If you are not the intended recipient, please 
contact the sender by reply e-mail and destroy all copies of the original 
message.

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Apache Fork Errors - Found on Windows Server 2019

[OwN-3m-All via Cygwin]

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://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Apache Fork Errors - Found on Windows Server 2019

[Ken Brown via Cygwin]

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 latest versions of these libs need to be reverted or properly fixed.


The new packages (using the previous build method, with no circular dependency) 
are now available.  Please test.


Ken

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Apache Fork Errors - Found on Windows Server 2019

[OwN-3m-All via Cygwin]

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 properly fixed.

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Apache Fork Errors - Found on Windows Server 2019

[Ken Brown via Cygwin]

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 the problem.


That did fix the problem!  I downgraded both and restarted, and now apache
and php works again.  


Just to double check, could you upgrade harfbuzz and freetype2 again and see if 
the problem comes back?  Make sure that there are no Cygwin processes running 
and that the _autorebase postinstall script completes successfully.  (You can 
check /var/log/setup.log.full for rebase messages.)



Can that change be reverted or fixed so that it
doesn't happen on future installs?


Yes, I'll revert that change if you can confirm as above that this really is the 
problem.


Ken

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Apache Fork Errors - Found on Windows Server 2019

[OwN-3m-All via Cygwin]

> 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 both and restarted, and now apache
and php works again.  Can that change be reverted or fixed so that it
doesn't happen on future installs?

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Apache Fork Errors - Found on Windows Server 2019

[Brian Inglis]

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 three different fresh installs of
different Windows operating systems (with no bloatware or BLODA), and all
of them had the same issue.


I have one other thought.  There was a recent packaging change in 
harfbuzz and freetype2 that introduced a circular dependency between the 
two:


   https://cygwin.com/pipermail/cygwin/2021-September/249316.html
   https://cygwin.com/pipermail/cygwin/2021-September/249317.html

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.


Is /etc/postinstall/0p_000_autorebase.dash rebase completing 
successfully after the new installs?


Maybe check and/or attach the cygwin install log /var/log/setup.log.full 
for dependency, install, or postinstall errors, and run


$ rebase -is > /var/log/rebase-is.log

on one of those systems and attach the log.

Is there a patch, update, or GP enabling ASLR on all processes?

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Apache Fork Errors - Found on Windows Server 2019

[Ken Brown via Cygwin]

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 operating systems (with no bloatware or BLODA), and all
of them had the same issue.


I have one other thought.  There was a recent packaging change in harfbuzz and 
freetype2 that introduced a circular dependency between the two:


  https://cygwin.com/pipermail/cygwin/2021-September/249316.html
  https://cygwin.com/pipermail/cygwin/2021-September/249317.html

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.


Ken

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Apache Fork Errors - Found on Windows Server 2019

[Andrey Repin]

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 clue.


-- 
With best regards,
Andrey Repin
Sunday, October 17, 2021 12:39:14

Sorry for my terrible english...


-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Apache Fork Errors - Found on Windows Server 2019

[OwN-3m-All via Cygwin]

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 all
of them had the same issue.

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Apache Fork Errors - Found on Windows Server 2019

[Ken Brown via Cygwin]

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 you see any 
unexpected DLLs being loaded.


Ken

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Apache Fork Errors - Found on Windows Server 2019

[OwN-3m-All via Cygwin]

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:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Apache Fork Errors - Found on Windows Server 2019

[OwN-3m-All via Cygwin]

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_info_fork::abort:
\??\C:\OGP64\bin\cygharfbuzz-0.dll: Loaded to different address:
parent(0x3FAF6) != child(0x60)
[Fri Oct 15 12:24:06.688016 2021] [mpm_prefork:error] [pid 1825]
(11)Resource temporarily unavailable: AH00159: fork: Unable to fork new
process
[Fri Oct 15 12:24:16.681209 2021] [mpm_prefork:notice] [pid 1825] AH00163:
Apache/2.4.39 (Unix) PHP/7.3.7 configured -- resuming normal operations
[Fri Oct 15 12:24:16.681308 2021] [core:notice] [pid 1825] AH00094: Command
line: '/usr/sbin/httpd -D NO_DETACH'
  1 [main] httpd 1830 child_info_fork::abort:
\??\C:\OGP64\bin\cygfreetype-6.dll: Loaded to different address:
parent(0x3FB5B) != child(0x8D)
[Fri Oct 15 12:24:19.369852 2021] [mpm_prefork:error] [pid 1825]
(11)Resource temporarily unavailable: AH00159: fork: Unable to fork new
process
[Fri Oct 15 12:24:29.392225 2021] [mpm_prefork:notice] [pid 1825] AH00169:
caught SIGTERM, shutting down
[Fri Oct 15 12:27:09.478958 2021] [mpm_prefork:error] [pid 1869]
(11)Resource temporarily unavailable: AH00159: fork: Unable to fork new
process
[Fri Oct 15 12:27:24.024483 2021] [mpm_prefork:notice] [pid 1869] AH00163:
Apache/2.4.39 (Unix) PHP/7.3.7 configured -- resuming normal operations
[Fri Oct 15 12:27:24.024548 2021] [core:notice] [pid 1869] AH00094: Command
line: '/usr/sbin/httpd -D NO_DETACH'
  0 [main] httpd 1909 child_info_fork::abort:
\??\C:\OGP64\bin\cygfreetype-6.dll: Loaded to different address:
parent(0x3FB5B) != child(0x60)
[Fri Oct 15 12:27:25.835937 2021] [mpm_prefork:error] [pid 1869]
(11)Resource temporarily unavailable: AH00159: fork: Unable to fork new
process
  0 [main] httpd 1914 child_info_fork::abort:
\??\C:\OGP64\bin\cygharfbuzz-0.dll: Loaded to different address:
parent(0x3FAF6) != child(0x60)
[Fri Oct 15 12:27:42.549492 2021] [mpm_prefork:error] [pid 1869]
(11)Resource temporarily unavailable: AH00159: fork: Unable to fork new
process
  1 [main] httpd 1922 child_info_fork::abort:
\??\C:\OGP64\bin\cygfreetype-6.dll: Loaded to different address:
parent(0x3FB5B) != child(0x8D)
[Fri Oct 15 12:27:57.590949 2021] [mpm_prefork:error] [pid 1869]
(11)Resource temporarily unavailable: AH00159: fork: Unable to fork new
process
  1 [main] httpd 1923 child_info_fork::abort:
\??\C:\OGP64\bin\cygharfbuzz-0.dll: Loaded to different address:
parent(0x3FAF6) != child(0x60)
[Fri Oct 15 12:28:12.382243 2021] [mpm_prefork:error] [pid 1869]
(11)Resource temporarily unavailable: AH00159: fork: Unable to fork new
process
  0 [main] httpd 1924 child_info_fork::abort:
\??\C:\OGP64\bin\cygfreetype-6.dll: Loaded to different address:
parent(0x3FB5B) != child(0x60)
[Fri Oct 15 12:28:24.538917 2021] [mpm_prefork:error] [pid 1869]
(11)Resource temporarily unavailable: AH00159: fork: Unable to fork new
process
  0 [main] httpd 1925 child_info_fork::abort:
\??\C:\OGP64\bin\cygharfbuzz-0.dll: Loaded to different address:
parent(0x3FAF6) != child(0x60)
[Fri Oct 15 12:28:35.535065 2021] [mpm_prefork:error] [pid 1869]
(11)Resource temporarily unavailable: AH00159: fork: Unable to fork new
process
  0 [main] httpd 1926 child_info_fork::abort:
\??\C:\OGP64\bin\cygfreetype-6.dll: Loaded to different address:
parent(0x3FB5B) != child(0xB5)
[Fri Oct 15 12:28:45.287653 2021] [mpm_prefork:error] [pid 1869]
(11)Resource temporarily unavailable: AH00159: fork: Unable to fork new
process
  0 [main] httpd 1927 child_info_fork::abort:
\??\C:\OGP64\bin\cygharfbuzz-0.dll: Loaded to different address:
parent(0x3FAF6) != child(0xB6)
[Fri Oct 15 12:28:54.918119 2021] [mpm_prefork:error] [pid 1869]
(11)Resource temporarily unavailable: AH00159: fork: Unable to fork new
process
  1 [main] httpd 1928 child_info_fork::abort:
\??\C:\OGP64\bin\cygfreetype-6.dll: Loaded to different address:
parent(0x3FB5B) != child(0x60)
[Fri Oct 15 12:29:02.690342 2021] [mpm_prefork:error] [pid 1869]
(11)Resource temporarily unavailable: AH00159: fork: Unable to fork new
process
  0 [main] httpd 1929 child_info_fork::abort:
\??\C:\OGP64\bin\cygharfbuzz-0.dll: Loaded to different address:
parent(0x3FAF6) != child(0xB7)
[Fri Oct 15 12:29:09.653496 2021] [mpm_prefork:error] [pid 1869]
(11)Resource temporarily unavailable: AH00159: fork: Unable to fork new
process
  0 [main] httpd 1930 child_info_fork::abort:
\??\C:\OGP64\bin\cygfreetype-6.dll: Loaded to different address:
parent(0x3FB5B) != child(0x9A)
[Fri Oct 15 12:29:15.852168 2021] [mpm_prefork:error] [pid 1869]
(11)Resource temporarily unavailable: AH00159: fork: Unable to fork new
process
  0 [main] httpd 1931 child_info_fork::abort:

Re: Apache Fork Errors - Found on Windows Server 2019

[OwN-3m-All via Cygwin]

> 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
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Apache Fork Errors - Found on Windows Server 2019

[Achim Gratz]

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 [main] httpd 153 child_info_fork::abort:
> \??\C:\OGP64\bin\cygfreetype-6.dll: Loaded to different address:
> parent(0x3FF1B) != child(0x60)
> [Thu Oct 14 20:35:28.557723 2021] [mpm_prefork:error] [pid 89] (11)Resource
> temporarily unavailable: AH00159: fork: Unable to fork new process
>
> I issued the "rebase-trigger fullrebase" command and ran the cygwin setup
> for it to rebase.  I rebooted the server, and that didn't make a difference.
>
> Any idea why this is happening or how to fix it?

Notice how _all_ images are mapped to the same (extremely low) address
even though they seem to be rebased properly as evidenced by their
address in the parent process.  I suggest you disable whatever BLODA
thinks it's a good idea to inject itself into Cygwin processes.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Apache Fork Errors - Found on Windows Server 2019

[OwN-3m-All via Cygwin]

> 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 that change, you just comment out the mpm_prefork.so line and
uncomment the mpm_worker.so line to change the mode in httpd.conf:

#LoadModule mpm_prefork_module modules/mod_mpm_prefork.so
LoadModule mpm_worker_module modules/mod_mpm_worker.so

But then, PHP no longer works, so that doesn't really help in this
situation, as I must have PHP working.  I believe the pre-forking mode used
to work previously.  I'm trying to test this in Windows 7 and 10 to confirm.

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Apache Fork Errors - Found on Windows Server 2019

[Mark Geisert]

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 Oct 14 20:21:24.306514 2021] [mpm_prefork:error] [pid 3203]
(11)Resource temporarily unavailable: AH00159: fork: Unable to fork new
process
[Thu Oct 14 20:21:32.643467 2021] [mpm_prefork:notice] [pid 3203] AH00163:
Apache/2.4.39 (Unix) PHP/7.3.7 configured -- resuming normal operations
[Thu Oct 14 20:21:32.643698 2021] [core:notice] [pid 3203] AH00094: Command
line: '/usr/sbin/httpd -D NO_DETACH'
[Thu Oct 14 20:21:32.644325 2021] [mpm_prefork:notice] [pid 3203] AH00169:
caught SIGTERM, shutting down

[etc etc etc]


I issued the "rebase-trigger fullrebase" command and ran the cygwin setup
for it to rebase.  I rebooted the server, and that didn't make a difference.


Makes sense to have tried that; thanks for reporting outcome.


Any idea why this is happening or how to fix it?


Been a long time since I've run Apache and that wasn't even on Cygwin, but...
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.


If somebody else on the list is successfully running Apache on Cygwin, maybe they 
can chime in on which mode they're using.

HTH,

..mark

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Apache Fork Errors - Found on Windows Server 2019

[OwN-3m-All via Cygwin]

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_prefork:error] [pid 3203]
(11)Resource temporarily unavailable: AH00159: fork: Unable to fork new
process
[Thu Oct 14 20:21:32.643467 2021] [mpm_prefork:notice] [pid 3203] AH00163:
Apache/2.4.39 (Unix) PHP/7.3.7 configured -- resuming normal operations
[Thu Oct 14 20:21:32.643698 2021] [core:notice] [pid 3203] AH00094: Command
line: '/usr/sbin/httpd -D NO_DETACH'
[Thu Oct 14 20:21:32.644325 2021] [mpm_prefork:notice] [pid 3203] AH00169:
caught SIGTERM, shutting down
[Thu Oct 14 20:22:59.254613 2021] [mpm_prefork:error] [pid 1357]
(11)Resource temporarily unavailable: AH00159: fork: Unable to fork new
process
[Thu Oct 14 20:23:09.058176 2021] [mpm_prefork:notice] [pid 1357] AH00163:
Apache/2.4.39 (Unix) PHP/7.3.7 configured -- resuming normal operations
[Thu Oct 14 20:23:09.058213 2021] [core:notice] [pid 1357] AH00094: Command
line: '/usr/sbin/httpd -D NO_DETACH'
  1 [main] httpd 1400 child_info_fork::abort:
\??\C:\OGP64\bin\cygfreetype-6.dll: Loaded to different address:
parent(0x3FB5B) != child(0x60)
[Thu Oct 14 20:23:10.331987 2021] [mpm_prefork:error] [pid 1357]
(11)Resource temporarily unavailable: AH00159: fork: Unable to fork new
process
  0 [main] httpd 1407 child_info_fork::abort:
\??\C:\OGP64\bin\cygharfbuzz-0.dll: Loaded to different address:
parent(0x3FAF6) != child(0xAD)
[Thu Oct 14 20:23:22.094868 2021] [mpm_prefork:error] [pid 1357]
(11)Resource temporarily unavailable: AH00159: fork: Unable to fork new
process
  0 [main] httpd 1409 child_info_fork::abort:
\??\C:\OGP64\bin\cygfreetype-6.dll: Loaded to different address:
parent(0x3FB5B) != child(0x60)
[Thu Oct 14 20:23:32.300480 2021] [mpm_prefork:error] [pid 1357]
(11)Resource temporarily unavailable: AH00159: fork: Unable to fork new
process
  0 [main] httpd 1412 child_info_fork::abort:
\??\C:\OGP64\bin\cygharfbuzz-0.dll: Loaded to different address:
parent(0x3FAF6) != child(0x8D)
[Thu Oct 14 20:23:43.420771 2021] [mpm_prefork:error] [pid 1357]
(11)Resource temporarily unavailable: AH00159: fork: Unable to fork new
process
  0 [main] httpd 1413 child_info_fork::abort:
\??\C:\OGP64\bin\cygfreetype-6.dll: Loaded to different address:
parent(0x3FB5B) != child(0x9B)
[Thu Oct 14 20:23:53.601627 2021] [mpm_prefork:error] [pid 1357]
(11)Resource temporarily unavailable: AH00159: fork: Unable to fork new
process
  0 [main] httpd 1414 child_info_fork::abort:
\??\C:\OGP64\bin\cygharfbuzz-0.dll: Loaded to different address:
parent(0x3FAF6) != child(0xAD)
[Thu Oct 14 20:24:03.920153 2021] [mpm_prefork:error] [pid 1357]
(11)Resource temporarily unavailable: AH00159: fork: Unable to fork new
process
  0 [main] httpd 1415 child_info_fork::abort:
\??\C:\OGP64\bin\cygfreetype-6.dll: Loaded to different address:
parent(0x3FB5B) != child(0x60)
[Thu Oct 14 20:24:14.022977 2021] [mpm_prefork:error] [pid 1357]
(11)Resource temporarily unavailable: AH00159: fork: Unable to fork new
process
  0 [main] httpd 1416 child_info_fork::abort:
\??\C:\OGP64\bin\cygharfbuzz-0.dll: Loaded to different address:
parent(0x3FAF6) != child(0x60)
[Thu Oct 14 20:24:25.140421 2021] [mpm_prefork:error] [pid 1357]
(11)Resource temporarily unavailable: AH00159: fork: Unable to fork new
process
  0 [main] httpd 1417 child_info_fork::abort:
\??\C:\OGP64\bin\cygfreetype-6.dll: Loaded to different address:
parent(0x3FB5B) != child(0x60)
[Thu Oct 14 20:24:35.263012 2021] [mpm_prefork:error] [pid 1357]
(11)Resource temporarily unavailable: AH00159: fork: Unable to fork new
process
  0 [main] httpd 1418 child_info_fork::abort:
\??\C:\OGP64\bin\cygharfbuzz-0.dll: Loaded to different address:
parent(0x3FAF6) != child(0x8D)
[Thu Oct 14 20:24:45.416030 2021] [mpm_prefork:error] [pid 1357]
(11)Resource temporarily unavailable: AH00159: fork: Unable to fork new
process
  0 [main] httpd 1419 child_info_fork::abort:
\??\C:\OGP64\bin\cygfreetype-6.dll: Loaded to different address:
parent(0x3FB5B) != child(0xAD)
[Thu Oct 14 20:24:55.546858 2021] [mpm_prefork:error] [pid 1357]
(11)Resource temporarily unavailable: AH00159: fork: Unable to fork new
process
  0 [main] httpd 1420 child_info_fork::abort:
\??\C:\OGP64\bin\cygharfbuzz-0.dll: Loaded to different address:
parent(0x3FAF6) != child(0x8D)
[Thu Oct 14 20:25:05.669908 2021] [mpm_prefork:error] [pid 1357]
(11)Resource temporarily unavailable: AH00159: fork: Unable to fork new
process
  0 [main] httpd 1421 child_info_fork::abort:
\??\C:\OGP64\bin\cygfreetype-6.dll: Loaded to different address:
parent(0x3FB5B) != child(0x8D)
[Thu Oct 14 20:25:15.798292 2021] [mpm_prefork:error] [pid 1357]
(11)Resource 

Re: fork errors

[Simon Matthews]

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 is to replace the ssh, Make and scripts with a
simpler set of scripts and processes controlled via the Gridengine.

Simon


On Tue, Apr 3, 2018 at 8:06 PM, Simon Matthews
<simon.d.matth...@gmail.com> wrote:
> 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 <juer...@wagner.is> wrote:
>> 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 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
>>>>
>>>> [...]
>>
>>

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: fork errors

[Simon Matthews]

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-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 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
>>>
>>> [...]
>
>

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: fork errors

[Tatsuro MATSUOKA]

- 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
> 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 followed the instruction to run "rebaseall" and this appears to have
> worked properly.
> 
> I suspect that the cause is that I am running a daemon that I compiled
> myself on a different instance of cygwin and then copied across. This
> daemon is not in the normal /usr tree.
> 
> Should I rebase the binaries associated with this daemon and, if so,
> how do I do this?
> 
> Simon
rebaseall does not see dll files on non-standard location.
I use e.g.
$ /usr/bin/rebase.exe -s -v /opt/gp530-qt/bin/*.dll
from dash.
Tatsuro


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: fork errors

[Jürgen Wagner]

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 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
>>
>> [...]




smime.p7s
Description: S/MIME Cryptographic Signature

Re: fork errors

[Marco Atzeri]

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, retry 0, exit code 0xC005, errno 11

I followed the instruction to run "rebaseall" and this appears to have
worked properly.

I suspect that the cause is that I am running a daemon that I compiled
myself on a different instance of cygwin and then copied across. This
daemon is not in the normal /usr tree.

Should I rebase the binaries associated with this daemon and, if so,
how do I do this?

Simon



Simon,
copied across what ?
Rebase is only for shared libraries; how is your demon implemented ?

Regards
Marco

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

fork errors

[Simon Matthews]

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 followed the instruction to run "rebaseall" and this appears to have
worked properly.

I suspect that the cause is that I am running a daemon that I compiled
myself on a different instance of cygwin and then copied across. This
daemon is not in the normal /usr tree.

Should I rebase the binaries associated with this daemon and, if so,
how do I do this?

Simon

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin 2.6.1 bash fork errors upon starting mintty

[Keith Christian]

Brian,

Thanks, with all Cygwin processes stopped, opening an ash.exe window
via start/run, then cd /bin and running rebaseall fixed the errors
present when I start mintty.

Keith

On Mon, Dec 26, 2016 at 9:43 AM, Brian Inglis
<brian.ing...@systematicsw.ab.ca> wrote:
> 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 should not matter)) when starting
>> mintty:
>>   0 [main] bash 6072 child_info_fork::abort:
>> C:\cygwin\bin\cygncursesw-10.dll: Loaded to different address:
>> parent(0x7526) != child(0x76)
>> -bash: fork: retry: Resource temporarily unavailable
>>   1 [main] bash 11040 child_info_fork::abort:
>> C:\cygwin\bin\cygncursesw-10.dll: Loaded to different address:
>> parent(0x7526) != child(0xEE)
>> -bash: fork: retry: No child processes
>
> Run "rebase-trigger fullrebase", shut down *ALL* Cygwin processes,
> download and run Setup.
>
>> CYGWIN_NT-10.0-WOW Keith-PC 2.6.1(0.305/5/3) 2016-12-16 11:50 i686 Cygwin
>
> If a full rebase does not fix it, you may have to uninstall some
> packages using Setup, and rerun the above process. You have limited
> address space under Cygwin 32 and may have to move to Cygwin 64.
>
>> Unfortunately, the cygcheck attachment was blocked by sourceware dot
>> org. What to do now?
>
> Ensure that your email is sent as text only and the attachment is sent
> as text - you may have to add .txt to cygcheck output file name to
> have it handled properly by your mail client.
>
> --
> Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
>
> --
> Problem reports:   http://cygwin.com/problems.html
> FAQ:   http://cygwin.com/faq/
> Documentation: http://cygwin.com/docs.html
> Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
>

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin 2.6.1 bash fork errors upon starting mintty

[Brian Inglis]

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 should not matter)) when starting
> mintty:
>   0 [main] bash 6072 child_info_fork::abort:
> C:\cygwin\bin\cygncursesw-10.dll: Loaded to different address:
> parent(0x7526) != child(0x76)
> -bash: fork: retry: Resource temporarily unavailable
>   1 [main] bash 11040 child_info_fork::abort:
> C:\cygwin\bin\cygncursesw-10.dll: Loaded to different address:
> parent(0x7526) != child(0xEE)
> -bash: fork: retry: No child processes

Run "rebase-trigger fullrebase", shut down *ALL* Cygwin processes, 
download and run Setup.
 
> CYGWIN_NT-10.0-WOW Keith-PC 2.6.1(0.305/5/3) 2016-12-16 11:50 i686 Cygwin

If a full rebase does not fix it, you may have to uninstall some 
packages using Setup, and rerun the above process. You have limited 
address space under Cygwin 32 and may have to move to Cygwin 64.

> Unfortunately, the cygcheck attachment was blocked by sourceware dot 
> org. What to do now?

Ensure that your email is sent as text only and the attachment is sent 
as text - you may have to add .txt to cygcheck output file name to 
have it handled properly by your mail client.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Cygwin 2.6.1 bash fork errors upon starting mintty

[Keith Christian]

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: Loaded to different address:
parent(0x7526) != child(0x76)
-bash: fork: retry: Resource temporarily unavailable
  1 [main] bash 11040 child_info_fork::abort:
C:\cygwin\bin\cygncursesw-10.dll: Loaded to different address:
parent(0x7526) != child(0xEE)
-bash: fork: retry: No child processes

CYGWIN_NT-10.0-WOW Keith-PC 2.6.1(0.305/5/3) 2016-12-16 11:50 i686 Cygwin

Unfortunately, the cygcheck attachment was blocked by sourceware dot
org.  What to do now?

Thanks, Cygwin team, for all that you do and the precious little
thanks that you receive.


== Keith

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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

[Achim Gratz]

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 asterisk for the following entries:

 /usr/bin/cygperl5_14.dll  base 0x0003fe9b size 0x0019 *
 /usr/lib/perl5/5.14/x86_64-cygwin-threads/CORE/cygperl5_14.dll   base
 0x0003fe9b size 0x0019 *

That's OK since the two paths are actually exactly the same file
(hard-linked).


Regards,
Achim.
-- 
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Fork errors in python2.7 on 64-bit Cygwin

[Michael Wild]

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
occupied. So far only Python shows this problem. E.g. the following
simple snippet regularly fails:

import subprocess
subprocess.check_call('sleep 1'.split())

* rebaseall doesn't help (even tried a fresh installation of Cygwin, a
clean PATH, etc).

* rebase -si only shows an asterisk for the following entries:

/usr/bin/cygperl5_14.dll  base 0x0003fe9b size 0x0019 *
/usr/lib/perl5/5.14/x86_64-cygwin-threads/CORE/cygperl5_14.dll   base
0x0003fe9b size 0x0019 *

  Given that they both belong to the same package and have the same
name, I tend to think that this is a spurious message that has nothing
to do with my problem. Nothing suspicious about cygz.dll in the output
(at least as far as I can tell).

* The 32-bit Cygwin installation is fine and never shows this behavior


Anybody got an idea how to get to the bottom of this problem?

Cheers

Michael

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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

[Michael Wild]

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 in my experience.


Thanks for your answer. Any suggestions on how I could find out what
is causing this? I found Corinna mentioning the hacking of cygwin.dll
by adding a call to sleep in the error handler in order to allow the
inspection of /proc/$PID/maps in an old thread, but perhaps there is
something more convenient now?

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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

[Andrey Repin]

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. Any suggestions on how I could find out what
 is causing this? I found Corinna mentioning the hacking of cygwin.dll
 by adding a call to sleep in the error handler in order to allow the
 inspection of /proc/$PID/maps in an old thread, but perhaps there is
 something more convenient now?

You can try enabling DLL inspection through CYGWIN environment variable for a
start.
http://cygwin.com/cygwin-ug-net/using-cygwinenv.html#cygwinenv-implemented-options


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 02.02.2015, 02:25

Sorry for my terrible english...


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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

[Steven Bardwell]

  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
  error -- 'No such file or  directory' -- when I try to spawn /bin/sh.
  I have attached the output from 'strace' on this process. If you look
at
  line 602, I think you can see where the exception gets generated. Can
  you see what is going on? I tried to create a simple test program that
  shows the problem, but (so far) they all work. Thanks.
 
  I am still trying to create a simple example, but the fact that it works
on
  the 32-bit
  install inspired me to look again at the strace output, comparing the
 output
  from
  the install that works with the 64-bit strace output that shows the
 problem.
 
 /bin/sh is crashing, for sure, but it's not clear to me why that would
 be the case.  It certainly has something to do with the way it's being
 invoked.  But whether that's the problem (i.e. GIGO) or whether there's
 something wrong on the Cygwin side that your usage is conveniently
 bringing to light, I can't say.  I'm assuming the former given your
 description so far.
 
 --
 Larry
 
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 trick works
fine in many flavors of Unix (including Interix and Linux and 32-bit
Cygwin).
However, in Cygwin 64-bit, it somehow corrupts things such that the
child process created by fork() or spawnv() failed to load correctly. After
removing that 'feature,' both spawnv() as well as the original fork() logic
work without any problem.

I really appreciate everyone's looking into this. 

Steve



--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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

[Steven Bardwell]

  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
  error -- 'No such file or  directory' -- when I try to spawn /bin/sh.
  I have attached the output from 'strace' on this process. If you look
at
  line 602, I think you can see where the exception gets generated. Can
  you see what is going on? I tried to create a simple test program that
  shows the problem, but (so far) they all work. Thanks.
 
  I am still trying to create a simple example, but the fact that it works
on
  the 32-bit
  install inspired me to look again at the strace output, comparing the
 output
  from
  the install that works with the 64-bit strace output that shows the
 problem.
 
 /bin/sh is crashing, for sure, but it's not clear to me why that would
 be the case.  It certainly has something to do with the way it's being
 invoked.  But whether that's the problem (i.e. GIGO) or whether there's
 something wrong on the Cygwin side that your usage is conveniently
 bringing to light, I can't say.  I'm assuming the former given your
 description so far.
 
 --
 Larry
 
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 trick works
fine in many flavors of Unix (including Interix and Linux and 32-bit
Cygwin).
However, in Cygwin 64-bit, it somehow corrupts things such that the
child process created by fork() or spawnv() failed to load correctly. After
removing that 'feature,' both spawnv() as well as the original fork() logic
work without any problem.

I really appreciate everyone's looking into this. 

Steve



--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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

[Andrey Repin]

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 trick works
 fine in many flavors of Unix (including Interix and Linux and 32-bit
 Cygwin).

CYGWIN=wincmdln
?

 However, in Cygwin 64-bit, it somehow corrupts things such that the
 child process created by fork() or spawnv() failed to load correctly. After
 removing that 'feature,' both spawnv() as well as the original fork() logic
 work without any problem.

Could still be NULL termination problem. If the strings you manipulating are
in UTF16, you need TWO \0 to terminate the string.


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 07.02.2014, 19:21

Sorry for my terrible english...


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: using spawn functions to avoid fork() errors

[Larry Hall (Cygwin)]

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 -
http://cygwin.com/cgi-
bin/cvsweb.cgi/src/winsup/cygwin/spawn.cc?rev=1.353content-
type=text/x-cvsweb-markupcvsroot=src


--
Larry



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
error -- 'No such file or  directory' -- when I try to spawn /bin/sh.
I have attached the output from 'strace' on this process. If you look at
line 602, I think you can see where the exception gets generated. Can
you see what is going on? I tried to create a simple test program that
shows the problem, but (so far) they all work. Thanks.


Interesting.  No, off hand, the strace output doesn't shed any light on
the situation for me either.  Clearly an access violation occurs when
/bin/sh is spawned but if it only happens in your specific code and not
in a simple invocation of spawn(), that suggests a possible usage problem.
I know, that's not much help. ;-)

--
Larry

_

A: Yes.
 Q: Are you sure?
 A: Because it reverses the logical flow of conversation.
 Q: Why is top posting annoying in email?

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

RE: using spawn functions to avoid fork() errors

[Steven Bardwell]

 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
  error -- 'No such file or  directory' -- when I try to spawn /bin/sh.
  I have attached the output from 'strace' on this process. If you look at
  line 602, I think you can see where the exception gets generated. Can
  you see what is going on? I tried to create a simple test program that
  shows the problem, but (so far) they all work. Thanks.
 
 Interesting.  No, off hand, the strace output doesn't shed any light on
 the situation for me either.  Clearly an access violation occurs when
 /bin/sh is spawned but if it only happens in your specific code and not
 in a simple invocation of spawn(), that suggests a possible usage problem.
 I know, that's not much help. ;-)
 
 --
 Larry
 
I am still trying to create a simple example, but the fact that it works on
the 32-bit
install inspired me to look again at the strace output, comparing the output
from
the install that works with the 64-bit strace output that shows the problem.

Can you look at this section?   /bin/sh (the program that is getting
spawned) 
gets loaded and starts running with PID 1464, but /bin/sh is failing :

   47 8674492 [main] ulpd 2116 child_info::sync: n 2, waiting for
subproc_ready(0x258) and child process(0x26C)
4   4 [main] sh (1464)
**
  296 300 [main] sh (1464) Program name: C:\cygwin64\bin\sh.exe (windows
pid 1464)
   52 352 [main] sh (1464) OS version:   Windows NT-6.1
   34 386 [main] sh (1464)
**
  233 619 [main] sh (1464) sigprocmask: 0 = sigprocmask (0, 0x1802BBC68,
0x0)
  287 906 [main] sh 1464 child_copy: cygheap - hp 0x254 low 0x1802DA410,
high 0x1802E46D0, res 1
  1221028 [main] sh 1464 child_copy: done --- Process 1464, exception
c005 at 0001800448D0

My process (PID=2116) creates the new process (/bin/sh with PID=1464), but
then /bin/sh craps out.
Does that shed any light on what might be the issue?

Steve




--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: using spawn functions to avoid fork() errors

[Larry Hall (Cygwin)]

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 spawnv() call is returning with an
error -- 'No such file or  directory' -- when I try to spawn /bin/sh.
I have attached the output from 'strace' on this process. If you look at
line 602, I think you can see where the exception gets generated. Can
you see what is going on? I tried to create a simple test program that
shows the problem, but (so far) they all work. Thanks.


Interesting.  No, off hand, the strace output doesn't shed any light on
the situation for me either.  Clearly an access violation occurs when
/bin/sh is spawned but if it only happens in your specific code and not
in a simple invocation of spawn(), that suggests a possible usage problem.
I know, that's not much help. ;-)

--
Larry


I am still trying to create a simple example, but the fact that it works on
the 32-bit
install inspired me to look again at the strace output, comparing the output
from
the install that works with the 64-bit strace output that shows the problem.

Can you look at this section?   /bin/sh (the program that is getting
spawned)
gets loaded and starts running with PID 1464, but /bin/sh is failing :

47 8674492 [main] ulpd 2116 child_info::sync: n 2, waiting for
subproc_ready(0x258) and child process(0x26C)
 4   4 [main] sh (1464)
**
   296 300 [main] sh (1464) Program name: C:\cygwin64\bin\sh.exe (windows
pid 1464)
52 352 [main] sh (1464) OS version:   Windows NT-6.1
34 386 [main] sh (1464)
**
   233 619 [main] sh (1464) sigprocmask: 0 = sigprocmask (0, 0x1802BBC68,
0x0)
   287 906 [main] sh 1464 child_copy: cygheap - hp 0x254 low 0x1802DA410,
high 0x1802E46D0, res 1
   1221028 [main] sh 1464 child_copy: done --- Process 1464, exception
c005 at 0001800448D0

My process (PID=2116) creates the new process (/bin/sh with PID=1464), but
then /bin/sh craps out.
Does that shed any light on what might be the issue?


/bin/sh is crashing, for sure, but it's not clear to me why that would
be the case.  It certainly has something to do with the way it's being
invoked.  But whether that's the problem (i.e. GIGO) or whether there's
something wrong on the Cygwin side that your usage is conveniently
bringing to light, I can't say.  I'm assuming the former given your
description so far.

--
Larry

_

A: Yes.
 Q: Are you sure?
 A: Because it reverses the logical flow of conversation.
 Q: Why is top posting annoying in email?

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: using spawn functions to avoid fork() errors

[David Conrad]

 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 cygwin does to treat
/bin/sh.exe and /bin/sh the same. What happens if you spawn
/bin/sh.exe instead of /bin/sh? Second, what happens if you use
spawnvp instead of spawnv? Although, from the strace excerpt it
doesn't look like it's actually having trouble finding the executable,
so those probably aren't it. Still, worth checking, perhaps.

Third, are you certain you are NULL-terminating the array of
arguments? If you aren't doing so explicitly, it is possible there
happened to be a NULL pointer just after the arguments in memory for
the 32-bit version, so it happened to work, but that didn't happen for
the 64-bit version. The argv array must have a NULL at the end of it.
Fourth, what are you passing to the mode parameter of spawnv?

Or, fifth, I dunno what the problem is. Those are my only ideas. Good luck.

David

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: using spawn functions to avoid fork() errors

[Larry Hall (Cygwin)]

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 pair with
only a little effort.), it sounds like there exists a family of API calls
that may help me avoid the 'Resource temporarily unavailable' errors from 
calling
fork().

However, I can't find any documentation on these spawn functions. I recoded
my application to use
posix_spawn() but I am getting the same 'Resource temporarily unavailable'
error so I suspect that it
is using fork() as well.


posix_spawn() comes from newlib and uses vfork.  You can take a look
at the code on-line for more info:

http://cygwin.com/cgi-bin/cvsweb.cgi/src/newlib/libc/posix/posix_spawn.c?rev=1.4content-type=text/x-cvsweb-markupcvsroot=src

An alternative that doesn't use fork was discussed here:

http://cygwin.com/ml/cygwin/2012-01/msg00032.html

The code referenced isn't part of Cygwin and may or may not work.  I have
no experience with it.  If you choose to use it, forward your comments and
questions directly to the author.


I did try the 'rebaseall' process to remove the error, but without any
success. I also checked the BLODA list.

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 - 
http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/spawn.cc?rev=1.353content-type=text/x-cvsweb-markupcvsroot=src



--
Larry

_

A: Yes.
 Q: Are you sure?
 A: Because it reverses the logical flow of conversation.
 Q: Why is top posting annoying in email?

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Fork errors during toolchain build

[marco atzeri]

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). Unfortunately, this means
there's no obvious culprit to target, because presumably the dlls bash,
sed, etc. use were rebased before the build ever started.

Is there some way I can diagnose more precisely what binaries/dlls are
responsible so I can rebase the right things? I can't rule out the
existence of custom dlls, but I did rebase everything newly-built that I
could find.

Thanks!
Ryan



I assume that for rebasing you are using
rebaseall -T your_additional_file_list
otherwise you could still have collisions.
See rebase -si output for details.

Are you sure is not a BLODA problem ?

About fork diagnostics, the latest snapshots have some
improvement, so you can try them

http://cygwin.com/snapshots/


Regards
Marco

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Fork errors during toolchain build

[Ryan Johnson]

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 no obvious culprit to target, because presumably the dlls bash, 
sed, etc. use were rebased before the build ever started.


Is there some way I can diagnose more precisely what binaries/dlls are 
responsible so I can rebase the right things? I can't rule out the 
existence of custom dlls, but I did rebase everything newly-built that I 
could find.


Thanks!
Ryan


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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

[Corinna Vinschen]

On Feb  6 06:42, Heiko Elger wrote:
 Hello,
 
 our current system is the following (cygwin installation is nearly up to 
 date).
 
 $ uname -a
 CYGWIN_NT-6.1-WOW64 PCFX163 1.7.10s(0.259/5/3) 20120111 22:39:26 i686 Cygwin
 
 some systems uses a newer snapshot:
 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) is already occupied
   7 [main] sh 88036 child_info_fork::abort: address space needed 
 by 'cygiconv-2.dll' (0x6D0D) is already occupied
 
 The error is extremely rarely - perhaps just once a day
 
 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 understand ASLR on Windows, it stores rebase addresses for DLLs
in a database and always uses the same values until reboot.

As for rebaseall, are you really sure?  You can inspect the values the
Cygwin DLLs are rebased to by running `rebase -s -i'.  If the output
contains asterisks after the base and size values of two adjacent DLLs,
they collide and need rebasing again.

 We have this error really not reproduceable on some compile machines.
 These machines are running a perl script which polls a remote database for 
 running make jobs in parallel (-j flag) - that's all.
 Normally all works fine - but sometimes we got these fork errors.
 
 Is there an possibility to get more information who is occupying the address 
 space?
 Perhaps I can instrument the cygwin1.dll to wait or do something special - so 
 I can use other tools i.e. sysinternals vmmap, process explorer ...
 to have a look who is using this address space.
 
 Perhaps a self build debug snapshot version with instrumented debug flags 
 will 
 give me some hints?

For a start, you could use the shiny new /proc/$PID/maps functionality
on the parent shell.  If you have a shell which fails to fork and you
can get it to wait, then fetch the pid from ps and call `less
/proc/$PID/maps' and see what is at 0x6d00.  If you want to stop
the child, you would have to build your own Cygwin DLL and add something
like a long Win32 Sleep() call after printing the above message in
child_info_fork::abort and then look into /proc/$PID/maps for that
process.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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

[Heiko Elger]

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 understand ASLR on Windows, it stores rebase addresses for DLLs
 in a database and always uses the same values until reboot.
 
Oops - I thought running rebaseall AND peflagsall is recommended on a win7/64 
system?

I just installed a full cygwin installation (without games/gnome/kde/audio) in 
another directory (please note: no snapshot installed) and did the follwing 
for testing how many dlls have ASLR bit set:

$find . -iname '*.dll' | xargs peflags -v 2/dev/null | grep '+dynamicbase' | 
wc -l

[fresh installation]
77 (is this OK?)

[old installation with peflagsall run]
1450

1450 DLLs !!! so perhaps this is real problem.

But what's about the other possible problem: tsawareness?
Should I set tsware for the DLLs - we always use remote desktop for connecting 
to other windows machines - so tsware should be set?
Is this correct?

What's the best to reinstall our system, cause I really not know which dll 
should have set dynamicbase or not?
Use cygwin setup option REINSTALL or remove installation and INSTALL?

 As for rebaseall, are you really sure?  You can inspect the values the
 Cygwin DLLs are rebased to by running `rebase -s -i'.  If the output
 contains asterisks after the base and size values of two adjacent DLLs,
 they collide and need rebasing again.
 
I know the new feature of rebase (nice feature) ...
I checked this already - there are no asterisks.

 
 For a start, you could use the shiny new /proc/$PID/maps functionality
 on the parent shell.  If you have a shell which fails to fork and you
 can get it to wait, then fetch the pid from ps and call `less
 /proc/$PID/maps' and see what is at 0x6d00.  If you want to stop
 the child, you would have to build your own Cygwin DLL and add something
 like a long Win32 Sleep() call after printing the above message in
 child_info_fork::abort and then look into /proc/$PID/maps for that
 process.
 

I know /proc/$PID/maps - nice feature too.

This sounds good, but is there a way doing this programatically - in an easy 
way.
Cause only delaying will not work - cause the error is runing on a remote 
machine ...
Or even prettier - print the name of the dll which uses the address space with 
using the /proc/$PID/maps contents.
I think this will be really helpfull for other users who have such an error.
This perhaps in combination with an environment setting in the CYGWIN variable 
would be really great feature.

Or is there an easy way for me to suspend the thread running into this error?
So I can start another shell for looking into /proc/$PID/maps.

I'm sorry - I'm really not an expert in cygwin programming ...
Perhaps you can give me a hint for suspending the thread/process?

Best regards

heiko







--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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

[Corinna Vinschen]

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, I think, reboot the machine.  As
  far as I understand ASLR on Windows, it stores rebase addresses for DLLs
  in a database and always uses the same values until reboot.
  
 Oops - I thought running rebaseall AND peflagsall is recommended on a win7/64 
 system?

No, that was a misunderstanding at one point.  I thought this has been
removed from the relevant docs.

 I just installed a full cygwin installation (without games/gnome/kde/audio) 
 in 
 another directory (please note: no snapshot installed) and did the follwing 
 for testing how many dlls have ASLR bit set:
 
 $find . -iname '*.dll' | xargs peflags -v 2/dev/null | grep '+dynamicbase' | 
 wc -l
 
 [fresh installation]
 77 (is this OK?)
 
 [old installation with peflagsall run]
 1450
 
 1450 DLLs !!! so perhaps this is real problem.
 
 But what's about the other possible problem: tsawareness?
 Should I set tsware for the DLLs - we always use remote desktop for 
 connecting 
 to other windows machines - so tsware should be set?
 Is this correct?

Yes and no.  Only executables need this flag, it's ignored on DLLs.
And, gcc sets this flag by default since 4.3.4, so I think there's no
reason to use it anymore.  Latest gcc 4.5.x also sets the large address
awareness flag on executables.  Advantage of that flag:  You get an
extra 2 Gigs of VM per process starting at 0x8000 on 64 bit systems.
Cygwin will put its application heap there, so you have more space in the
lower 2 Gigs for DLL rebasing.

 What's the best to reinstall our system, cause I really not know which dll 
 should have set dynamicbase or not?

None of it, actually.

 Use cygwin setup option REINSTALL or remove installation and INSTALL?

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.

  As for rebaseall, are you really sure?  You can inspect the values the
  Cygwin DLLs are rebased to by running `rebase -s -i'.  If the output
  contains asterisks after the base and size values of two adjacent DLLs,
  they collide and need rebasing again.
  
 I know the new feature of rebase (nice feature) ...
 I checked this already - there are no asterisks.

Hmm, too bad.

  For a start, you could use the shiny new /proc/$PID/maps functionality
  on the parent shell.  If you have a shell which fails to fork and you
  can get it to wait, then fetch the pid from ps and call `less
  /proc/$PID/maps' and see what is at 0x6d00.  If you want to stop
  the child, you would have to build your own Cygwin DLL and add something
  like a long Win32 Sleep() call after printing the above message in
  child_info_fork::abort and then look into /proc/$PID/maps for that
  process.
  
 
 I know /proc/$PID/maps - nice feature too.
 
 This sounds good, but is there a way doing this programatically - in an easy 
 way.
 Cause only delaying will not work - cause the error is runing on a remote 
 machine ...
 Or even prettier - print the name of the dll which uses the address space 
 with 
 using the /proc/$PID/maps contents.
 I think this will be really helpfull for other users who have such an error.
 This perhaps in combination with an environment setting in the CYGWIN 
 variable 
 would be really great feature.

The great feature would be if the problem didn't occur at all.  But
that's just idle wishing, I guess.

 Or is there an easy way for me to suspend the thread running into this error?
 So I can start another shell for looking into /proc/$PID/maps.

That's what I meant.  Add a Sleep(10L) to child_info_fork::abort,
right before the `ExitProcess (EXITCODE_FORK_FAILED)' and build a
Cygwin DLL.  Then, if it happens, the process will linger for 100 seconds,
which is enough time to inspect /proc/$PID/maps using less.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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

[Heiko Elger]

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
   be the culprit.  Try resetting it and, I think, reboot the machine.  As
   far as I understand ASLR on Windows, it stores rebase addresses for DLLs
   in a database and always uses the same values until reboot.
   
  Oops - I thought running rebaseall AND peflagsall is recommended on a 
win7/64 
  system?
 
 No, that was a misunderstanding at one point.  I thought this has been
 removed from the relevant docs.

That's possible - I cannot find this documentation now - but I'm really sure 
that I'd read this some months ago.

 
  I just installed a full cygwin installation (without 
games/gnome/kde/audio) in 
  another directory (please note: no snapshot installed) and did the 
follwing 
  for testing how many dlls have ASLR bit set:
  
  $find . -iname '*.dll' | xargs peflags -v 2/dev/null | 
grep '+dynamicbase' | 
  wc -l
  
  [fresh installation]
  77 (is this OK?)
  
  [old installation with peflagsall run]
  1450
  
  1450 DLLs !!! so perhaps this is real problem.
  
  But what's about the other possible problem: tsawareness?
  Should I set tsware for the DLLs - we always use remote desktop for 
connecting 
  to other windows machines - so tsware should be set?
  Is this correct?
 
 Yes and no.  Only executables need this flag, it's ignored on DLLs.
 And, gcc sets this flag by default since 4.3.4, so I think there's no
 reason to use it anymore.  Latest gcc 4.5.x also sets the large address
 awareness flag on executables.  Advantage of that flag:  You get an
 extra 2 Gigs of VM per process starting at 0x8000 on 64 bit systems.
 Cygwin will put its application heap there, so you have more space in the
 lower 2 Gigs for DLL rebasing.

Oops - that was my personal error - I know tsawareness is set to EXE files 
only.

 
  What's the best to reinstall our system, cause I really not know which dll 
  should have set dynamicbase or not?
 
 None of it, actually.
 
  Use cygwin setup option REINSTALL or remove installation and INSTALL?
 
 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 counting dlls with dynamicbase flag already set - in a fresh 
installation. So over 77 dlls have set this flag.
Or do you mean to remove the flag on really all DLLs?

So - why do not REINSTALL/INSTALL?
Are there any benefits - expect for the effort of time.


Just two question beyond the scope of this posting:
What's the best and easy way to duplicate a cygwin installation to 25 other 
machines?
How to completely remove an cygwin installation includeing registry settings?


best regards

Heiko


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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

[Corinna Vinschen]

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 counting dlls with dynamicbase flag already set - in a fresh 
 installation. So over 77 dlls have set this flag.
 Or do you mean to remove the flag on really all DLLs?

Yes, exactly.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

extremely rarely fork errors: who occuppies the space?

[Heiko Elger]

Hello,

our current system is the following (cygwin installation is nearly up to date).

$ uname -a
CYGWIN_NT-6.1-WOW64 PCFX163 1.7.10s(0.259/5/3) 20120111 22:39:26 i686 Cygwin

some systems uses a newer snapshot:
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) is already occupied
  7 [main] sh 88036 child_info_fork::abort: address space needed 
by 'cygiconv-2.dll' (0x6D0D) is already occupied

The error is extremely rarely - perhaps just once a day

Antivirus software is deinstalled, Windows defender is deactivated.
Rebaseall and peflagsall were running.

We have this error really not reproduceable on some compile machines.
These machines are running a perl script which polls a remote database for 
running make jobs in parallel (-j flag) - that's all.
Normally all works fine - but sometimes we got these fork errors.

Is there an possibility to get more information who is occupying the address 
space?
Perhaps I can instrument the cygwin1.dll to wait or do something special - so 
I can use other tools i.e. sysinternals vmmap, process explorer ...
to have a look who is using this address space.

Perhaps a self build debug snapshot version with instrumented debug flags will 
give me some hints?

Please - can anyone give me some hints.
Any help is welcome.

best regards

Heiko



--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

how to log fork errors, cygheap errors with syslogd

[Heiko Elger]

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 - or is it not possible to log these 
kind of errors.

My syslog.conf file has only one entry.
* snip sni snip *
*.* /var/log/messages
* snip sni snip *

Any help welcome.

I'm sorry - but I use syslogd the first time.


best regards 

Heiko Elger



--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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

[Corinna Vinschen]

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 there.
 How do I have to configure my syslogd - or is it not possible to log these 
 kind of errors.

No, it's not.  The messages are printed using special debug output
functions, not the syslog API.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

help for diagnose unpedictable fork errors, cygheap base msimatch errors

[Heiko Elger]

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. runing perl:
child_info_fork::abort: address space needed by 'IO.dll' (009D) is already 
occupied

2. running perl
0 [main] perl 22992 C:\programme\cygwin\bin\perl.exe: *** fatal error - cy
gheap base mismatch detected - 0x612527E0/0xF927E0.
This problem is probably due to using incompatible versions of the cygwin DLL.
Search for cygwin1.dll using the Windows Start-Find/Search facility
and delete all but the most recent version.  The most recent version *should*
reside in x:\cygwin\bin, where 'x' is the drive on which you have
installed the cygwin distribution.  Rebooting is also suggested if you
are unable to find another cygwin DLL.

-- there is definitely no other currrent cygwin1.dll

3. running sh.exe from within make
0 [main] sh 5564 child_info_fork::abort data segment start: parent(0x682000) !
= child(0x32000) m.sh fork: retry: Resource temorarily unavailable

4. running make
0 [main] make-3.80 22116 child_info::sync: wait failed, pid 21196, Win32 error 
1892

How can I gather more informations about the problems with other cygwin tools. 
I'm definitely no cygwin professional.
I already tried strace - I have an strace log of problem 1.) - if this would 
be helpful, I can post it.

OK - I already checked the BLODA -  and yes one is running on our system - 
Symantec Endpoint Protection Version 12.x.

We deinstalled it on 3 PCs - perhaps we will see no more error there.

But cause of unpedictable errors and no testcase it's not a solution to 
deinstall it on all machines.

Is there a testcase for detecting Symantec as the real problem - we are in 
contact with Symantec too.
Does anyone know the problem of using Symantec Endpoint Protection a little 
bit in details.
Is it possible that the unloading of DLL code is delayed?

I noticed in http://article.gmane.org/gmane.os.cygwin/129594 that there is an 
existing error - so I will give the the next snapshot a try.

@cfg:
Can this http://article.gmane.org/gmane.os.cygwin/129594 the reason for our 
problems too?

Any hints are welcome.

best regards

Heiko Elger


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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

[marco atzeri]

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 testcase.
I noticed the following problems:

1. runing perl:
child_info_fork::abort: address space needed by 'IO.dll' (009D) is already
occupied

2. running perl
0 [main] perl 22992 C:\programme\cygwin\bin\perl.exe: *** fatal error - cy
gheap base mismatch detected - 0x612527E0/0xF927E0.
This problem is probably due to using incompatible versions of the cygwin DLL.
Search for cygwin1.dll using the Windows Start-Find/Search facility
and delete all but the most recent version.  The most recent version *should*
reside in x:\cygwin\bin, where 'x' is the drive on which you have
installed the cygwin distribution.  Rebooting is also suggested if you
are unable to find another cygwin DLL.

--  there is definitely no other currrent cygwin1.dll

3. running sh.exe from within make
0 [main] sh 5564 child_info_fork::abort data segment start: parent(0x682000) !
= child(0x32000) m.sh fork: retry: Resource temorarily unavailable

4. running make
0 [main] make-3.80 22116 child_info::sync: wait failed, pid 21196, Win32 error
1892

How can I gather more informations about the problems with other cygwin tools.
I'm definitely no cygwin professional.
I already tried strace - I have an strace log of problem 1.) - if this would
be helpful, I can post it.

OK - I already checked the BLODA -  and yes one is running on our system -
Symantec Endpoint Protection Version 12.x.

We deinstalled it on 3 PCs - perhaps we will see no more error there.

But cause of unpedictable errors and no testcase it's not a solution to
deinstall it on all machines.

Is there a testcase for detecting Symantec as the real problem - we are in
contact with Symantec too.
Does anyone know the problem of using Symantec Endpoint Protection a little
bit in details.
Is it possible that the unloading of DLL code is delayed?

I noticed in http://article.gmane.org/gmane.os.cygwin/129594 that there is an
existing error - so I will give the the next snapshot a try.

@cfg:
Can this http://article.gmane.org/gmane.os.cygwin/129594 the reason for our
problems too?

Any hints are welcome.

best regards

Heiko Elger



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 using 2011-11-08 snapshot  on win7/64 and it is working 
fine (2011-11-14 has a problem and I have not yet tested 2011-11-16)


Regards
Marco


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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

[Heiko Elger]

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 am currently using 2011-11-08 snapshot  on win7/64 and it is working 
 fine (2011-11-14 has a problem and I have not yet tested 2011-11-16)
 
 Regards
 Marco
 
 
I'm sorry - but I'm not sure what you mean exactly.

Perhaps my english is too bad - I'm sorry for this.
Or I'm writing to many lines ...

We've some unpredictabel errors and I'm looking for a solution to gather more 
information about the erros to send them perhaps into this group - so other 
people can perhaps help.

Regards
Heiko







--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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

[Ryan Johnson]

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 data we can not easly help you.

I am currently using 2011-11-08 snapshot  on win7/64 and it is working
fine (2011-11-14 has a problem and I have not yet tested 2011-11-16)

Regards
Marco



I'm sorry - but I'm not sure what you mean exactly.

Perhaps my english is too bad - I'm sorry for this.
Or I'm writing to many lines ...

We've some unpredictabel errors and I'm looking for a solution to gather more
information about the erros to send them perhaps into this group - so other
people can perhaps help.
If you follow the instructions on the web page Marco highlighted, you'll 
have a good start at gathering the information we need to help you.


Ryan


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: 1.7 fork errors in Win7

[Luis P Caamano]

Eliot,

I got some time to re-read the rebase read me file this weekend and
I'm now a bit more uncertain about your recommendation.  If I
understand correctly, you're saying I should mark ALL (almost at
least, I don'tknow  what not to yet) dlls, exes and sos as not ASLR
compatible and then rebase with enough space between them so they are
separate enough that they can be loaded in the same place by Window's
loader without conflict.

So, it seems we are simply taking the Windows loader out of the
business of loading DLLs et all in the same memory location for all
concurrent processes.

If so, then:

How do I figure out what binaries don't need to be rebased and
peflaged?  Trial and error?
Why not use rebaseall and peflagsall instead?

Thanks,

Luis P Caamano
Atlanta, GA USA



On Wed, Dec 2, 2009 at 3:41 PM, Luis P Caamano wrote:
 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 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 (details follow):
 svn: Can't create tunnel: Resource temporarily unavailable

 This is not limited to svn of course, just one example.  My cygwin
 environment is very usable as these are not that frequent but every
 time I'm thinking all is well, one of these comes up to remind me it's
 not.

 Is this a known issue?
 Is there any information I can provide to help debug and fix this?
 Is there anything I can do on my end to investigate the issue?

 Thanks in advance for all your work on 1.7, it's looking good.

 This smells like collisions with Windows dll's, which can happen
 somewhat randomly because of Address Space Randomization in recent
 Windows OSs.  What fixes it for me is suitably rebasing all cygwin
 dll, so, and exe files appropriately.

 Details:

 /bin/rebase -d -b 0x6100 -o 0x2 -v -T file with list of dll and so 
 files  rebase.out

 and

 /bin/peflags -d0 -v -T file with list of dll and so files  peflags-d.out
 /bin/peflags -t0 -v -T file with list of exe files         peflags-t.out

 Corinna and others say that this should not be necessary, but I get problems
 with certain forking programs if I don't do it. Note the -o flag, which makes
 sure that items are far enough apart that certain metadata does not cause
 problems.

 Do read up on how to use rebase and peflags! They need to be called from ash,
 not bash, since otherwise soe of the dll's will be open. Also, I have found
 the need to drop one or two specific files from the list of *all* so, dll, 
 and
 exe files that I build with find, so do check the output, etc.

 Regards -- Eliot Moss


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

1.7 fork errors in Win7

[Luis P Caamano]

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 (details follow):
svn: Can't create tunnel: Resource temporarily unavailable

This is not limited to svn of course, just one example.  My cygwin
environment is very usable as these are not that frequent but every
time I'm thinking all is well, one of these comes up to remind me it's
not.

Is this a known issue?
Is there any information I can provide to help debug and fix this?
Is there anything I can do on my end to investigate the issue?

Thanks in advance for all your work on 1.7, it's looking good.

-- 
Luis P Caamano
Atlanta, GA USA


cygcheck.out
Description: Binary data
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: 1.7 fork errors in Win7

[Eliot Moss]

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 11
svn: Commit failed (details follow):
svn: Can't create tunnel: Resource temporarily unavailable

This is not limited to svn of course, just one example.  My cygwin
environment is very usable as these are not that frequent but every
time I'm thinking all is well, one of these comes up to remind me it's
not.

Is this a known issue?
Is there any information I can provide to help debug and fix this?
Is there anything I can do on my end to investigate the issue?

Thanks in advance for all your work on 1.7, it's looking good.


This smells like collisions with Windows dll's, which can happen
somewhat randomly because of Address Space Randomization in recent
Windows OSs.  What fixes it for me is suitably rebasing all cygwin
dll, so, and exe files appropriately.

Details:

/bin/rebase -d -b 0x6100 -o 0x2 -v -T file with list of dll and so files 
 rebase.out

and

/bin/peflags -d0 -v -T file with list of dll and so files  peflags-d.out
/bin/peflags -t0 -v -T file with list of exe files peflags-t.out

Corinna and others say that this should not be necessary, but I get problems
with certain forking programs if I don't do it. Note the -o flag, which makes
sure that items are far enough apart that certain metadata does not cause
problems.

Do read up on how to use rebase and peflags! They need to be called from ash,
not bash, since otherwise soe of the dll's will be open. Also, I have found
the need to drop one or two specific files from the list of *all* so, dll, and
exe files that I build with find, so do check the output, etc.

Regards -- Eliot Moss

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: 1.7 fork errors in Win7

[Luis P Caamano]

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 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 (details follow):
 svn: Can't create tunnel: Resource temporarily unavailable

 This is not limited to svn of course, just one example.  My cygwin
 environment is very usable as these are not that frequent but every
 time I'm thinking all is well, one of these comes up to remind me it's
 not.

 Is this a known issue?
 Is there any information I can provide to help debug and fix this?
 Is there anything I can do on my end to investigate the issue?

 Thanks in advance for all your work on 1.7, it's looking good.

 This smells like collisions with Windows dll's, which can happen
 somewhat randomly because of Address Space Randomization in recent
 Windows OSs.  What fixes it for me is suitably rebasing all cygwin
 dll, so, and exe files appropriately.

 Details:

 /bin/rebase -d -b 0x6100 -o 0x2 -v -T file with list of dll and so 
 files  rebase.out

 and

 /bin/peflags -d0 -v -T file with list of dll and so files  peflags-d.out
 /bin/peflags -t0 -v -T file with list of exe files         peflags-t.out

 Corinna and others say that this should not be necessary, but I get problems
 with certain forking programs if I don't do it. Note the -o flag, which makes
 sure that items are far enough apart that certain metadata does not cause
 problems.

 Do read up on how to use rebase and peflags! They need to be called from ash,
 not bash, since otherwise soe of the dll's will be open. Also, I have found
 the need to drop one or two specific files from the list of *all* so, dll, and
 exe files that I build with find, so do check the output, etc.

 Regards -- Eliot Moss



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.10.0\loaders\cygpixbufloader-xpm.dll to
same address as parent: 0x3F != 0x5B
  2 [main] gvim 7844 fork: child 7580 - died waiting for dll
loading, errno 11

After that, gvim hangs and I have to kill it.

That seems like the same issue and it could also be solved with a
proper rebase, right?


-- 
Luis P Caamano
Atlanta, GA USA

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: 1.7 fork errors in Win7

[Eliot Moss]

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.10.0\loaders\cygpixbufloader-xpm.dll to
same address as parent: 0x3F != 0x5B
  2 [main] gvim 7844 fork: child 7580 - died waiting for dll
loading, errno 11

After that, gvim hangs and I have to kill it.

That seems like the same issue and it could also be solved with a
proper rebase, right?


Same deal :-) ... EM

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: perl fork errors with a cygwin dll?

[Eric Blake]

-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/h/Backup/coLinux'
9648 [main] perl 4064 d:\cygwin\bin\perl.exe: *** fatal error -
 unable to remap d:\cygwin\bin\cygexpat-0.dll to same address as
 parent(0xB8) != 0xD0
   5 [main] perl 3420 fork: child 4064 - died waiting for dll
 loading, errno 11

For this error, it sounds like you are a good candidate for running
rebaseall.  See /usr/share/doc/Cygwin/rebase-2.4.3.README for details.

 Any help, hints, or pointers on what I might look at or provide for
 information? My cygwin binaries are all up to date as of last night...

Proving that, by including 'cygcheck -svr' output as an attachment, as
requested here, would be nice...
 Problem reports:   http://cygwin.com/problems.html

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGA8dN84KuGfSFAYARAu5cAJ9eeXErl4F8UdY85q0MejvLNNfC9wCgyGKK
kDE4AbBReDamWdD4JnWnWWg=
=rNQY
-END PGP SIGNATURE-

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: perl fork errors with a cygwin dll?

[Larry Hall (Cygwin)]

[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 -
unable to remap d:\cygwin\bin\cygexpat-0.dll to same address as
parent(0xB8) != 0xD0


  

That's an indication of a DLL's address space conflicting with another.
Can't have that and expect fork to work.  The solution, as always with
this kind of problem, is to install the rebase package, read the readme
in /usr/share/doc/Cygwin, and follow its directions to run 'rebaseall'.


--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (508) 893-9889 - FAX
Holliston, MA 01746

_

A: Yes.
 Q: Are you sure?
 A: Because it reverses the logical flow of conversation.
 Q: Why is top posting annoying in email?

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

perl fork errors with a cygwin dll?

[cygwin]

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\bin\cygexpat-0.dll to same address as
parent(0xB8) != 0xD0
  5 [main] perl 3420 fork: child 4064 - died waiting for dll
loading, errno 11
panic: MUTEX_LOCK (45) [util.c:2266] at bin/backup.pl line 217.
panic: MUTEX_LOCK (45) [op.c:354].

As well, when it does work, I seem to get a large number of :
WARNING: %s failed verification -- update discarded (will try again).
(where %s is replaced, obviously, with a file name being transfered.

I went digging around and found this old thread relating to the first
http://cygwin.com/ml/cygwin/2005-09/msg00014.html
but no real answers.

To the second, I find only references that it should be very rare, but
I seem to be getting it a lot lately (several times per rsync run on
~89k file tree).

Any help, hints, or pointers on what I might look at or provide for
information? My cygwin binaries are all up to date as of last night...

Jason


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

fork errors - search snips from cygwin mailing list archive

[Tom Rodman]

I egreped thru (my local copy of) the cygwin archives back to ~3/2005 for:

  fork: No such file or directory
  died waiting for longjmp
  fork: Bad file
  fork: Resource temporarily unavai

Please see end of this post for snips from this grep. The
results suggest a fair number of users had the problem, I'd be
curious how many convinced themselves their problems are gone; 
can we identify which of the cases are solved?

We're still seeing these non repeatable errors (now using the 9/22
snapshot on a development box). No test case is enclosed. 

A fairly recent cygcheck.out for the computer having the problems is an
attachment in:

  http://sourceware.org/ml/cygwin/2005-09/msg00796.html

If you can show me our box is out of resources, that would be great -
see the attachment for RAM, a list of processes, and more- it's a Compaq
ProLiant DL380 G3. It is behind a firewall 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 up until quite a few cygwin
bash and perl scripts have already run ok. Once it happens, it may be
fairly repeatable, until I stop all cygwin services, kill all cygwin
processes; then the fork errors are gone for a while again.  

I do most interactive CLI work in ssh bash login sessions. I see fewer
of these fork errors in 1.5.18, and in the Sept snapshots. 

Friday 9/23, I was debugging a fairly simple bash shell script, with
a few traps, and functions - I had several vim sessions suspended,
and 2 ssh sessions. Here are some fork errors from Friday (using snaphot:
1.5.19s(0.138/4/2) 20050922):

  $ ci -l a_small_text_file
  -bash: fork: Resource temporarily unavailable
  $

  snip
  $ lt
  -bash: fork: Resource temporarily unavailable
  snip
  $ which lt
  lt is aliased to `cmd /c dir /od|d2u|egrep -v DIR +RCS$|\.\.?$| [0-9]+ 
(Dir|File)|tail -8'
  snip

  $ ./a_mediumsized_bashscript
  /adm/bin/win/service_restart02.shinc: fork: Resource temporarily unavailable
   10 [main] ? 0 fork_copy: cygheap for exec pass 0 failed, 
0x6115A900..0x61160834, done 0, windows pid 2816, Win32 error 5

  # Another problem on Friday: an interactive ssh session for no apparent reason
  # just died.  This has happened in the past, see:
  #   http://sourceware.org/ml/cygwin/2005-07/msg01006.html
  #
  # The good news is this happens less than in 1.5.17.
  # For more detail on this see last ~30 lines of this post.

We continue to use 1.3.20 and it is just about problem free, it just
works - I look forward to that level of stability. 
Oh well.. it's our end user perspective. New features and speed are great,
but stabiility and reliablity get's the job done over and over. I've
been looking for a stable cygwin release since 1.5.10, and have not been
convinced. If that sounds arrogant, sorry, it's not meant to be, it
is honest. We use cygwin to control over night windows software builds
with bash scripts, so when the build breaks we don't want cygwin blamed.

I appreciate all the cygwin developers' hard work, I love the tools!

We're in a position to upgrade cygwin on 9 servers, 3 of which
will be purchased in the next couple of months. :-

--
thanks again,
Tom Rodman

--
See below for the snippets { enclosed in curly
braces }.  This is an egrep of last ~200 days of cygwin archives for:

  fork: No such file or directory
  died waiting for longjmp
  fork: Bad file
  fork: Resource temporarily unavai

--v-v--C-U-T---H-E-R-E-v-v-- 
{
  {
  According to David Arnstein on 8/18/2005 1:01 AM:
   Frequently (but not always) I will launch a Cygwin command window
   running bash; the new command window prints a message from bash:
  
   --
10 [main] bash 1880 pinfo::wait: Couldn't create pipe tracker for
   pid 3768,
  
Win32 error 231
   bash: fork: Resource temporarily unavailable
   --

  This is not a bug in bash, but a limitation in the number of running
  processes under Windows.  When cygwin cannot create a new process during a
  fork(), you will get this behavior.  Some people have reported success
  turning off (or swapping) antivirus programs, or other tricks to reduce
  the number of running processes on their system.  Other than that, I don't
  have any further ideas that might help you.

  - --
  Life is short - so eat dessert first!

  Eric Blake 
  }
  {
   This is not a bug in bash, but a limitation in the number of running
   processes under Windows.  When cygwin cannot create a new process during a
   fork(), you will get this behavior.  Some people have reported success
   turning off (or swapping) antivirus programs, or other tricks to reduce
   the number

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

[Tom Rodman]

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 swapped in the 9/22 snapshot (without rebooting). The
errors are gone - the test ran cleanly 4 times in a row.   I swapped back in
the 9/19 snapshot (w/o rebooting) and again it ran cleanly multiple times.

In general what might explain the unhappy state cygwin got into,
before I killed off all cygwin processes (sshd, cron, incoming and
out going ssh sessions, bash shells, vim, less..)?

 The test script works (always?) without errors on 1.3.20.
 
 1.3.20?  That is at least three years old.  There is nothing useful that
 can be derived from quoting a regression from a version which is that
 old.

The 1.3.20 test is on a production server.  The errors were
on a separate development server.

Our production boxes will be upgraded from 1.3.20 when I can
show our scripts work reliably with the latest cygwin.  

My cygwin tests are done mainly on the development box. 
This is at least the second time that my errors could not be
duplicated by others - it is a dual processor server with 
hyperthreading on, cygcheck.out is
attached.  It runs about 10 cron jobs nightly, and reboots weekly.

 I can't reproduce this, even with 81 repetitions instead of 9.  Please
 see the snapshot reporting guidelines that I requested at
 http://sources.redhat.com/ml/cygwin/2005-09/msg00419.html .

I've read it now.  To comply, I would need to be a more active/systematic
tester - I'll see what I can do ;)

 Here are a couple of test runs:
 
   ~ $ /tmp/test
   x: 1
   x: 2
   x: 3
   x: 4
   x: 5
   x: 6
   x: 7
   x: 8
   x: 9
   896 [main] bash 6544 fork_parent: child 6680 died waiting for longjmp 
  before initialization
   /tmp/test: fork: No such file or directory
 
   all done
   ~ $ /tmp/test
   x: 1
   x: 2
   x: 3
   x: 4
   x: 5
   x: 6
   x: 7
   x: 8
   x: 9
   /tmp/test: fork: No such file or directory
   812 [main] bash 7028 fork_parent: child 3576 died waiting for longjmp 
  before initialization
   /tmp/test: fork: Bad file descriptor
 
   all done
 
 --
 With a real (ie useful) script (that also involved a sleep) I was able to
 get similar(?) errors after running only 5 instances of that
 script in parallel.
 
 
 do nothing test script:
 --v-v--C-U-T---H-E-R-E-v-v-- 
 #!/bin/bash
 
 bar()
 {
 
   foo=$(
 echo $(
   perl -pe '1;' /etc/passwd|
   tee /dev/null|
   (sleep 7;tr '[A-Z]' '[a-z]') |
   tail -1
 )
   )
 
   echo foo: $foo /dev/null
 
 }
 
 
 for x in 1 2 3 4 5 6 7 8 9
 do
   echo x: $x
   bar 
 done
 
 wait
 echo
 echo all done
 


Cygwin Configuration Diagnostics
Current System Time: Wed Sep 21 17:44:35 2005

Windows 2000 Advanced Server Ver 5.0 staffuser2 2195 Service Pack 4

Path:   c:\aut\cyg\home\local\staffuser1\bin
c:\aut\cyg\home\local\staffuser1\bin
c:\aut\cyg\bin
c:\aut\m
c:\aut\ulb
i:\tcm\adm\bin\sys
i:\tcm\adm\bin\app
c:\aut\cyg\contrib\bin
c:\bcm63\bin
c:\bcm63\jre\bin
c:\bcm63\bin\util
c:\WINNT\system32
c:\WINNT
c:\WINNT\System32\Wbem
c:\Program Files\Resource Kit\
c:\Program Files\Support Tools\
c:\PROGRA~1\BMCSOF~1\common\globalc\bin\Windows-x86
c:\Progra~1\tivoli\tsm\baclient
c:\HPOV\bin
c:\HPOV\bin\OpC
.\

Output from c:\aut\cyg\bin\id.exe (nontsec)
UID: 15773(staffuser1)  GID: 16027(XYZ_ES_STAFF)
544(Administrators)  10513(Domain Users)  16026(XYZ_ES_ADMIN)
16027(XYZ_ES_STAFF)  16024(XYZ_Users) 545(Users)

Output from c:\aut\cyg\bin\id.exe (ntsec)
UID: 15773(staffuser1)  GID: 16027(XYZ_ES_STAFF)
544(Administrators)  10513(Domain Users)  16026(XYZ_ES_ADMIN)
16027(XYZ_ES_STAFF)  16024(XYZ_Users) 545(Users)

SysDir: C:\WINNT\system32
WinDir: C:\WINNT

USER = `staffuser1'
PWD = `/adm/bin/sys/s'
CYGWIN = `binmode tty ntsec smbntsec'
HOME = `/home/local/staffuser1'
MAKE_MODE = `UNIX'

rv = `/adm/backup/recovery'
HOMEPATH = `\aut\cyg\home\local\staffuser1'
cfl = `/adm/sa/cfglog'
MANPATH = `:/usr/ssl/man'
hostname = `OurServer108'
D = `/drv'
LCL_PATH_ADM = `i:/tcm'
TERM = `vt100'
SHELL = `/bin/bash'
PROCESSOR_IDENTIFIER = `x86 Family 15 Model 2 Stepping 7, GenuineIntel'
DIRCMD = `/A'
WINDIR = `C:\WINNT'
SSH_CLIENT = `10.165.10.182 37067 22'
cu = `/adm/bin/cust'
OLDPWD = `/home/local/staffuser1'
USERDOMAIN = `DOMxx1\'
SSH_TTY = `/dev/tty0'
OS = `Windows_NT'
ALLUSERSPROFILE = `C:\Documents and Settings\All Users'
dc = `/adm/doc'
XCM_MKEP01_DB = `\\OurServer108\bcmdb\xyzp01test'
svars_bash_defined = `yes'
BASH_BIN = `c:\aut\cyg\bin'
PATH_ADM = `i:/tcm'
http_proxy = `http://proxy.OurBiz.com:8080'
rg = `C:\WINNT\system32\config'
TEMP = 

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

[Tom Rodman]

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: 5
  x: 6
  x: 7
  x: 8
  x: 9
  896 [main] bash 6544 fork_parent: child 6680 died waiting for longjmp 
before initialization
  /tmp/test: fork: No such file or directory

  all done
  ~ $ /tmp/test
  x: 1
  x: 2
  x: 3
  x: 4
  x: 5
  x: 6
  x: 7
  x: 8
  x: 9
  /tmp/test: fork: No such file or directory
  812 [main] bash 7028 fork_parent: child 3576 died waiting for longjmp 
before initialization
  /tmp/test: fork: Bad file descriptor

  all done

--
With a real (ie useful) script (that also involved a sleep) I was able to
get similar(?) errors after running only 5 instances of that
script in parallel.


do nothing test script:
--v-v--C-U-T---H-E-R-E-v-v-- 
#!/bin/bash

bar()
{

  foo=$(
echo $(
  perl -pe '1;' /etc/passwd|
  tee /dev/null|
  (sleep 7;tr '[A-Z]' '[a-z]') |
  tail -1
)
  )

  echo foo: $foo /dev/null

}


for x in 1 2 3 4 5 6 7 8 9
do
  echo x: $x
  bar 
done

wait
echo
echo all done





--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

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

[Christopher Faylor]

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 least three years old.  There is nothing useful that
can be derived from quoting a regression from a version which is that
old.

I can't reproduce this, even with 81 repetitions instead of 9.  Please
see the snapshot reporting guidelines that I requested at
http://sources.redhat.com/ml/cygwin/2005-09/msg00419.html .

cgf


Here are a couple of test runs:

  ~ $ /tmp/test
  x: 1
  x: 2
  x: 3
  x: 4
  x: 5
  x: 6
  x: 7
  x: 8
  x: 9
  896 [main] bash 6544 fork_parent: child 6680 died waiting for longjmp 
 before initialization
  /tmp/test: fork: No such file or directory

  all done
  ~ $ /tmp/test
  x: 1
  x: 2
  x: 3
  x: 4
  x: 5
  x: 6
  x: 7
  x: 8
  x: 9
  /tmp/test: fork: No such file or directory
  812 [main] bash 7028 fork_parent: child 3576 died waiting for longjmp 
 before initialization
  /tmp/test: fork: Bad file descriptor

  all done

--
With a real (ie useful) script (that also involved a sleep) I was able to
get similar(?) errors after running only 5 instances of that
script in parallel.


do nothing test script:
--v-v--C-U-T---H-E-R-E-v-v-- 
#!/bin/bash

bar()
{

  foo=$(
echo $(
  perl -pe '1;' /etc/passwd|
  tee /dev/null|
  (sleep 7;tr '[A-Z]' '[a-z]') |
  tail -1
)
  )

  echo foo: $foo /dev/null

}


for x in 1 2 3 4 5 6 7 8 9
do
  echo x: $x
  bar 
done

wait
echo
echo all done





--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/