Re: Fork Failures

Anne Linden writes: > My machine started having fork failures, so I found the documentation > on fork failures and am trying to fix it. However the rebaseall -v > command will not run. I only ever get back the response "only ash or > dash processes are allowed during rebasin

RE: Fork Failures

> > My machine started having fork failures, so I found the documentation on fork > failures and am trying to fix it. However the rebaseall -v command will not > run. > I only ever get back the response "only ash or dash processes are allowed > during > rebasing Exi

RE: Fork Failures

>-Original Message- >From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of >Anne Linden >Sent: Wednesday, April 29, 2015 10:06 AM >To: cygwin@cygwin.com >Subject: Fork Failures > >However when I run ps -a it only lists the bash process and

Fork Failures

Hi, My machine started having fork failures, so I found the documentation on fork failures and am trying to fix it. However the rebaseall -v command will not run. I only ever get back the response "only ash or dash processes are allowed during rebasing Exit all Cygwin processes and sto

Re: fixing BLODA-caused fork failures

On 08/10/2013 3:34 PM, Larry Hall (Cygwin) wrote: On 10/8/2013 3:25 PM, David Boyce wrote: But as a point of practicality, 64-bit Cygwin can help with some cases of DLL address space collisions. So if you haven't experimented with 64-bit Cygwin in your environment, it may be worth your time.

Re: fixing BLODA-caused fork failures

On 10/8/2013 3:25 PM, David Boyce wrote: But as a point of practicality, 64-bit Cygwin can help with some cases of DLL address space collisions. So if you haven't experimented with 64-bit Cygwin in your environment, it may be worth your time. This sounds very reasonable but I'm curious: is it

Re: fixing BLODA-caused fork failures

> But as a point of practicality, 64-bit Cygwin can help with some cases of > DLL address space collisions. So if you haven't experimented with > 64-bit Cygwin in your environment, it may be worth your time. This sounds very reasonable but I'm curious: is it to date just a theory that makes sense

Re: fixing BLODA-caused fork failures

Am 03.10.2013 22:55, schrieb Adam Kellas: My company uses Cygwin and we experience fairly frequent fork failures, believed to be BLODA-related. I say "believed to be" because in this corporate environment, like many, we cannot uninstall the virus scanner even long enough to see wh

Re: fixing BLODA-caused fork failures

On Thu, Oct 03, 2013 at 04:55:19PM -0400, Adam Kellas wrote: >My company uses Cygwin and we experience fairly frequent fork >failures, believed to be BLODA-related. I say "believed to be" because >in this corporate environment, like many, we cannot uninstall the >virus scann

Re: fixing BLODA-caused fork failures

On 10/3/2013 5:50 PM, Ryan Johnson wrote: On 03/10/2013 4:55 PM, Adam Kellas wrote: My company uses Cygwin and we experience fairly frequent fork failures, believed to be BLODA-related. I say "believed to be" because in this corporate environment, like many, we cannot uninstall

Re: fixing BLODA-caused fork failures

On 03/10/2013 4:55 PM, Adam Kellas wrote: My company uses Cygwin and we experience fairly frequent fork failures, believed to be BLODA-related. I say "believed to be" because in this corporate environment, like many, we cannot uninstall the virus scanner even long enough to see wh

fixing BLODA-caused fork failures

My company uses Cygwin and we experience fairly frequent fork failures, believed to be BLODA-related. I say "believed to be" because in this corporate environment, like many, we cannot uninstall the virus scanner even long enough to see what happens without it. The presumed culprit in o

Re: Two probable basing issues causing fork failures: (1) cygreadline7.dll has ASLR enabled, (2) default base address conflicts with ASLR-relocated/system DLLs

On Mon, Apr 23, 2012 at 05:58:23PM +0200, Corinna Vinschen wrote: >On Apr 23 11:44, Christopher Faylor wrote: >> On Mon, Apr 23, 2012 at 04:51:06PM +0200, Corinna Vinschen wrote: >> >On Apr 23 14:23, James Johnston wrote: >> >> Perhaps I did not make it clear enough, but these issues still exist as

Re: Two probable basing issues causing fork failures: (1) cygreadline7.dll has ASLR enabled, (2) default base address conflicts with ASLR-relocated/system DLLs

On Apr 23 16:31, James Johnston wrote: > > As for the address space, we should stick to using the addresses below > > 0x7000, top-down. The reason is that we also need room for the > > application heap. On 32 bit systems the heap will be placed at 0x2000 > > and in case it's too small it

Re: Two probable basing issues causing fork failures: (1) cygreadline7.dll has ASLR enabled, (2) default base address conflicts with ASLR-relocated/system DLLs

On Apr 23 12:20, Ken Brown wrote: > On 4/23/2012 11:58 AM, Corinna Vinschen wrote: > >In theory that's the job of peflags, not of rebase. And somebody could > >want the ASLR flag to be set on certain DLLs. But probably we can safely > >assume that the Cygwin distro DLLs should not have set the dy

RE: Two probable basing issues causing fork failures: (1) cygreadline7.dll has ASLR enabled, (2) default base address conflicts with ASLR-relocated/system DLLs

> -Original Message- > Sent: Monday, April 23, 2012 14:51 > Subject: Re: Two probable basing issues causing fork failures: (1) > cygreadline7.dll has ASLR enabled, (2) default base address conflicts with > ASLR-relocated/system DLLs > > Yes, it is a problem in the fir

Re: Two probable basing issues causing fork failures: (1) cygreadline7.dll has ASLR enabled, (2) default base address conflicts with ASLR-relocated/system DLLs

On 4/23/2012 11:58 AM, Corinna Vinschen wrote: On Apr 23 11:44, Christopher Faylor wrote: On Mon, Apr 23, 2012 at 04:51:06PM +0200, Corinna Vinschen wrote: On Apr 23 14:23, James Johnston wrote: Perhaps I did not make it clear enough, but these issues still exist as far as I can tell. I have

Re: Two probable basing issues causing fork failures: (1) cygreadline7.dll has ASLR enabled, (2) default base address conflicts with ASLR-relocated/system DLLs

On Apr 23 11:44, Christopher Faylor wrote: > On Mon, Apr 23, 2012 at 04:51:06PM +0200, Corinna Vinschen wrote: > >On Apr 23 14:23, James Johnston wrote: > >> Perhaps I did not make it clear enough, but these issues still exist as far > >> as I can tell. I have clean Windows 7 and Windows XP virtua

Re: Two probable basing issues causing fork failures: (1) cygreadline7.dll has ASLR enabled, (2) default base address conflicts with ASLR-relocated/system DLLs

On Mon, Apr 23, 2012 at 04:51:06PM +0200, Corinna Vinschen wrote: >On Apr 23 14:23, James Johnston wrote: >> Perhaps I did not make it clear enough, but these issues still exist as far >> as I can tell. I have clean Windows 7 and Windows XP virtual machines, and >> a clean install of Cygwin that w

Re: Two probable basing issues causing fork failures: (1) cygreadline7.dll has ASLR enabled, (2) default base address conflicts with ASLR-relocated/system DLLs

On Apr 23 08:54, Eric Blake wrote: > On 04/23/2012 08:51 AM, Corinna Vinschen wrote: > >> If having Windows randomly rebase cygreadline7.dll in a child process via > >> ASLR is not a problem, I'd simply be interested to know why. I thought > >> *any* Cygwin DLL relocating itself would cause fork t

Re: Two probable basing issues causing fork failures: (1) cygreadline7.dll has ASLR enabled, (2) default base address conflicts with ASLR-relocated/system DLLs

On 04/23/2012 08:51 AM, Corinna Vinschen wrote: >> If having Windows randomly rebase cygreadline7.dll in a child process via >> ASLR is not a problem, I'd simply be interested to know why. I thought >> *any* Cygwin DLL relocating itself would cause fork to fail. > > Yes, it is a problem in the fi

Re: Two probable basing issues causing fork failures: (1) cygreadline7.dll has ASLR enabled, (2) default base address conflicts with ASLR-relocated/system DLLs

On Apr 23 14:23, James Johnston wrote: > Perhaps I did not make it clear enough, but these issues still exist as far > as I can tell. I have clean Windows 7 and Windows XP virtual machines, and > a clean install of Cygwin that was updated at the time I sent my original > message. Both issues I de

RE: Two probable basing issues causing fork failures: (1) cygreadline7.dll has ASLR enabled, (2) default base address conflicts with ASLR-relocated/system DLLs

20, 2012 20:50 Subject: Re: Two probable basing issues causing fork failures: (1) cygreadline7.dll has ASLR enabled, (2) default base address conflicts with ASLR-relocated/system DLLs On Fri, Apr 20, 2012 at 05:44:38PM -, James Johnston wrote: >[snip] >... Today this issue came >

Re: Two probable basing issues causing fork failures: (1) cygreadline7.dll has ASLR enabled, (2) default base address conflicts with ASLR-relocated/system DLLs

On Fri, Apr 20, 2012 at 05:44:38PM -, James Johnston wrote: >[snip] >... Today this issue came >to a head on one installation of Cygwin 1.7.9,... >[snip] >Thoughts, anyone? Yep. Update your Cygwin installation. You're four revisions out of date. It should come not too great a surprise that

Two probable basing issues causing fork failures: (1) cygreadline7.dll has ASLR enabled, (2) default base address conflicts with ASLR-relocated/system DLLs

Hi, Before I describe the issues I think I've found, I'd like to clarify my understanding. In the past, I have periodically run into random issues when starting new programs from the bash shell. The errors are always random and cryptic ("bad address", etc. - that sort of thing). Today this issu

Re: fork failures in git rebase

Am 07.12.2011 19:16 schrieb Eric Blake: > On 12/07/2011 11:12 AM, Rafael Kitover wrote: >> I was doing a "git rebase origin/master" today on a repo, and I saw alot >> of this: >> >> 7 [main] sh 6120 C:\cygwin\bin\sh.exe: *** fatal error - couldn't >> allocate heap, Win32 error 487, base 0xAD0

Re: fork failures in git rebase

On 12/07/2011 11:12 AM, Rafael Kitover wrote: > I was doing a "git rebase origin/master" today on a repo, and I saw alot > of this: > > 7 [main] sh 6120 C:\cygwin\bin\sh.exe: *** fatal error - couldn't > allocate heap, Win32 error 487, base 0xAD, top 0xB4, > > The same errors were

SOLVED (was: Re: fixing fork failures (was: Re: Best way to repair cygwin?))

> > This is typically the result of one of two things: > > > > 1. > > > > 2. DLL collisions - Install the 'rebase' package, read its README in > > /usr/share/doc/Cygwin, and follow the instructions there to run > > 'rebaseall'. Thanks a lot! In my

Re: fixing fork failures (was: Re: Best way to repair cygwin?)

On 26/08/2011 9:22 AM, Ronald Fischer wrote: 9420794 [main] sh 8004 exception::handle: Exception: STATUS_ACCESS_VIOLATION sh: fork: retry: Resource temporarily unavailable I had run setup again yesterday evening I wonder whether there is an easy way to "repair" Cygwin Quoting Larry's recent res

Re: Random fork failures

On 13/7/2011 12:55, Corinna Vinschen wrote: Building Cygwin in debug mode and access to the source tree helps a lot. The only problem is that this crash only reproduce when compiling with -O2 -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/f

Re: Random fork failures

On Jul 13 12:47, yoni levi wrote: > On 13/7/2011 10:32, Corinna Vinschen wrote: > >I still have > >to point out, though, that I can not reproduce this problem. Neither > >with a debug DLL, nor with an optimized DLL > I managed to catch this inside gdb (run "gdb rxvt" from mintty). > but the backtr

Re: Random fork failures

On 13/7/2011 10:32, Corinna Vinschen wrote: I still have to point out, though, that I can not reproduce this problem. Neither with a debug DLL, nor with an optimized DLL I managed to catch this inside gdb (run "gdb rxvt" from mintty). but the backtrace seems useless to me. Any ideas how to impr

Re: Random fork failures

On Jul 13 12:29, yoni levi wrote: > On 13/7/2011 10:32, Corinna Vinschen wrote: > >Please call addr2line for all addresses starting with 61. In the > >above example that would be: > > > > $ addr2line -e /bin/cygwin1.dll 6100749B 61004EFC 61004F84 61006499 > > > > $ addr2line -e /bin/cygwin1.dll

Re: Random fork failures

On 13/7/2011 10:32, Corinna Vinschen wrote: Please call addr2line for all addresses starting with 61. In the above example that would be: $ addr2line -e /bin/cygwin1.dll 6100749B 61004EFC 61004F84 61006499 $ addr2line -e /bin/cygwin1.dll 61116FEF 610C30EB 610C7605 0040524B 0040107B 610

Re: Random fork failures

On 13/7/2011 10:32, Corinna Vinschen wrote: The access violation occurs inside the Cygwin DLL, but the address is useless without the DLL. Since you built the DLL yourself, you would have to look where this crash occurs. You should have a rxvt.exe.stackdump file with function addresses, kind of

Re: Random fork failures

On Jul 13 09:32, Corinna Vinschen wrote: > On Jul 12 15:31, yoni levi wrote: > > now the 1_7_10 strace log > > > --- Process 3776, exception C005 at 61116FEF > >67 4739866 [main] rxvt 3776 exception::handle: In cygwin_except_handler > > exc 0xC005 at 0x61116FEF sp 0x22CAAC > >59 4

Re: Random fork failures

On Jul 12 15:31, yoni levi wrote: > now the 1_7_10 strace log > --- Process 3776, exception C005 at 61116FEF >67 4739866 [main] rxvt 3776 exception::handle: In cygwin_except_handler > exc 0xC005 at 0x61116FEF sp 0x22CAAC >59 4739925 [main] rxvt 3776 exception::handle: In cygwin_ex

Re: Random fork failures

On Jul 12 15:30, yoni levi wrote: > On 12/7/2011 12:29, Corinna Vinschen wrote: > >On Jul 12 10:31, yoni levi wrote: > >>On 12/7/2011 10:23, Corinna Vinschen wrote: > > I am also attaching strace.txt with the output of: > > ~$ strace install a /etc/b > >>>And it worked, didn't it? Your s

Re: Random fork failures

On 12/7/2011 16:18, Fergus wrote: (People recommend mintty for 1.7 and probably with very good reasons, but I still quite like rxvt.) my rxvt does not hang, all rxvt windows just disappear. with mintty it works perfectly. -- Problem reports: http://cygwin.com/problems.html FAQ:

Re: Random fork failures

>> Right. But rxvt crash. > I have no such problems with rxvt. Only incidental to the matters you have raised, but for what it's worth: Not quite certain what you mean by "rxvt crash" but with 1.7 I have repeatedly experienced "rxvt hang" - the rxvt session proceeds perfectly well until Ctrl

Re: Random fork failures

On Jul 12 10:31, yoni levi wrote: > On 12/7/2011 10:23, Corinna Vinschen wrote: > >>> I am also attaching strace.txt with the output of: > >>> ~$ strace install a /etc/b > >And it worked, didn't it? Your strace looks normal, no exception occured. > > > > > Right. But rxvt crash. I have no such

Fwd: Re: Random fork failures

On 12/7/2011 10:23, Corinna Vinschen wrote: > I am also attaching strace.txt with the output of: > ~$ strace install a /etc/b And it worked, didn't it? Your strace looks normal, no exception occured. Right. But rxvt crash. bash.exe is still running though. -- Problem reports:

Re: Random fork failures

On 12/7/2011 10:23, Corinna Vinschen wrote: > I am also attaching strace.txt with the output of: > ~$ strace install a /etc/b And it worked, didn't it? Your strace looks normal, no exception occured. Right. But rxvt crash. -- Problem reports: http://cygwin.com/problems.html FAQ:

Re: Random fork failures

On Jul 11 16:51, yoni levi wrote: > On 11/7/2011 15:04, Corinna Vinschen wrote: > >cygcheck -svr output as perhttp://cygwin.com/problems.html might give > >some clue as well... > > > > I am also attaching strace.txt with the output of: > ~$ strace install a /etc/b And it worked, didn't it? Your

Re: Random fork failures

On Jul 11 16:44, yoni levi wrote: > > > >>Actually, I have not the faintest idea. Can you build your own Cygwin > >>DLL without -O2, see if it still occurs, and run that scenario through > >>GDB? > >cygcheck -svr output as per http://cygwin.com/problems.html might give > >some clue as well... >

Re: Random fork failures

On Mon, Jul 11, 2011 at 12:14:22PM -0700, Marc Girod wrote: >Christopher Faylor wrote: >> >> Actually, I think it is more likely BLODA. >> >The other standard reply (I am surprised not to read it in this thread) is >rebaseall. Doh. Good point. Yes. What he said. cgf -- Problem reports:

Re: Random fork failures

every rebase will raise the base address where to load injected DLLs. Is this just fantasy and rain dancing? [ A fork error with scp may get my system to hang so that I need to reboot ] Marc -- View this message in context: http://old.nabble.com/Random-fork-failures-tp32035530p32040454.html Sent f

Re: Random fork failures

On Mon, Jul 11, 2011 at 01:27:52PM -0400, Chris Sutcliffe wrote: >On 11 July 2011 09:44, yoni levi wrote: Actually, I have not the faintest idea. ?Can you build your own Cygwin DLL without -O2, see if it still occurs, and run that scenario through GDB? >>> >>> cygcheck -svr output as

Re: Random fork failures

On 11 July 2011 09:44, yoni levi wrote: >>> Actually, I have not the faintest idea.  Can you build your own Cygwin >>> DLL without -O2, see if it still occurs, and run that scenario through >>> GDB? >> >> cygcheck -svr output as per http://cygwin.com/problems.html might give >> some clue as well...

Re: Random fork failures

On Jul 11 13:47, Corinna Vinschen wrote: > On Jul 11 13:24, Yoni Londner wrote: > > > > > >WJFFM, both. There's something in your environment which isn't in mine. > > >Did you set $CYGWIN? > > > > > > > ~$ echo $CYGWIN > > nodosfilewarning > > That's not the problem. It still works for me, with

Re: Random fork failures

Actually, I have not the faintest idea. Can you build your own Cygwin DLL without -O2, see if it still occurs, and run that scenario through GDB? I am on it. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http:/

Re: Random fork failures

On Jul 11 13:24, Yoni Londner wrote: > > > >WJFFM, both. There's something in your environment which isn't in mine. > >Did you set $CYGWIN? > > > > ~$ echo $CYGWIN > nodosfilewarning That's not the problem. It still works for me, with the snapshot as well as with CVS. > That's a clean installa

Re: Random fork failures

That's a clean installation. what can cause this kind of crashes? I tried again with cygwin1.dll from latest snapshot (http://cygwin.org/snapshots/cygwin1-20110711.dll.bz2) I am not sure if this will be helpful, but these are the md5sum for the relevant files: ~$ md5sum /usr/bin/install /us

Re: Random fork failures

WJFFM, both. There's something in your environment which isn't in mine. Did you set $CYGWIN? ~$ echo $CYGWIN nodosfilewarning That's a clean installation. what can cause this kind of crashes? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/

Re: Random fork failures

On Jul 11 12:27, Yoni Londner wrote: > On 11/7/2011 12:02, Corinna Vinschen wrote: > >I tested both scripts on W7 32 and 2K8R2 against the latest snapshot, > >as well as against self-built current Cygwin CVS, built with and without > >optimization. Both scripts run fine in all scenarios. > > > on

Re: Random fork failures

I did a little investigation - when the process hangs, I took the backtrace with process explorer. Process explorer does not know anything about cygwin debug symbols, so it just give an arbitrary func + offset. Then I used gdb to find out the real function: sync_proc_pipe doing yield in an endle

Re: Random fork failures

On 11/7/2011 12:02, Corinna Vinschen wrote: I tested both scripts on W7 32 and 2K8R2 against the latest snapshot, as well as against self-built current Cygwin CVS, built with and without optimization. Both scripts run fine in all scenarios. on a clean cygwin installation (1.7.9) and new cygwin1

Re: Random fork failures

On Jul 11 11:36, Yoni Londner wrote: > > > >>I will appreciate any advice, how can I solve this problem. > > > >Simple, self-contained testcases, preferredly in plain C, or simple > >scripts in case the problem only occurs in a script language, which > >allow to reproduce the problem. Those would

Re: Random fork failures

Example 1: #!/usr/bin/perl use POSIX qw(getcwd); getcwd(); 1; Example 2: #!/usr/bin/perl use Scalar::Util qw(looks_like_number); looks_like_number("1"); 1; Both end up with: Segmentation fault (core dumped) Well, I tried these two examples on a clean cygwin installation, with new cygwin1.d

Re: Random fork failures

I will appreciate any advice, how can I solve this problem. Simple, self-contained testcases, preferredly in plain C, or simple scripts in case the problem only occurs in a script language, which allow to reproduce the problem. Those would be most helpful. Corinna Example 1: #!/usr/bin/p

Re: Random fork failures

On Jul 11 11:07, yoni levi wrote: > Hi, > > We have a problem with fork for a very long time. > From time to time, fork just hangs (with 2 process doing busy loop). > The problem occurs when we do allot of spawns (make system). > It is very easy to recreate the problem, but unfortunately, there is

Random fork failures

Hi, We have a problem with fork for a very long time. From time to time, fork just hangs (with 2 process doing busy loop). The problem occurs when we do allot of spawns (make system). It is very easy to recreate the problem, but unfortunately, there is too much code involve to send. I did a li

Re: Intermittent fork failures

On Tue, 4 Oct 2005, Christopher Faylor wrote: > On Tue, Oct 04, 2005 at 01:02:50PM -0400, Igor Pechtchanski wrote: > >I've been getting intermittent "fork: Resource Temporarily Unavailable" > >errors with 1.5.18 and snapshots. AFAICT, the resources are there. > > http://sources.redhat.com/ml/cygw

Re: Intermittent fork failures

On Oct 4 13:02, Igor Pechtchanski wrote: > Hi, > > I've been getting intermittent "fork: Resource Temporarily Unavailable" > errors with 1.5.18 and snapshots. AFAICT, the resources are there. > > I was able to reproduce both the succeeding and the failing case under > strace, but, to my untrain

Re: Intermittent fork failures

On Tue, Oct 04, 2005 at 01:02:50PM -0400, Igor Pechtchanski wrote: >I've been getting intermittent "fork: Resource Temporarily Unavailable" >errors with 1.5.18 and snapshots. AFAICT, the resources are there. http://sources.redhat.com/ml/cygwin/2005-09/msg00945.html -- Unsubscribe info: http

Intermittent fork failures

Hi, I've been getting intermittent "fork: Resource Temporarily Unavailable" errors with 1.5.18 and snapshots. AFAICT, the resources are there. I was able to reproduce both the succeeding and the failing case under strace, but, to my untrained eye, it doesn't contain much relevant information. T