This issue was resolved after a pc restart, thanx.
On Sun, 13 Apr 2025 at 09:07, Siva kumar wrote:
> Hi all,
> My Cygwin was working perfectly until yesterday. I installed Python 3.13
> and pip and Ansible through Win powershell. I think this corrupted cygwin.
> Now Cygwin is giving fork errors
On 2/4/2021 9:29 AM, Hamish McIntyre-Bhatty via Cygwin wrote:
> Hi all,
>
> I managed to improve my Cygwin VM's performance significantly using a
> variety of methods.
>
> If anyone else is experiencing troubles, seeing what I changed at
> https://www.hamishmb.com/blog/improving-cygwins-performanc
On 03/12/2012 5:23 AM, Techie Help wrote:
Hi,
As suggested by Marco, I stripped the PATH to bare minimum and then it started
building.
But slowly slowly, one at a time, I started adding more paths to path variable
and finally I have restored it back to old one but its now building without any
Hi,
As suggested by Marco, I stripped the PATH to bare minimum and then it started
building.
But slowly slowly, one at a time, I started adding more paths to path variable
and finally I have restored it back to old one but its now building without any
problem.
So, I am not sure what happened.
On Sat, Dec 01, 2012 at 09:32:38AM +0100, marco atzeri wrote:
>On 11/30/2012 5:24 PM, Techie Help wrote:
>> I have set up a new PC and installed cygwin on it.
>> Its windows 7 pro.
>>
>> Whenever I try to build our application on it, I get the following error:
>>
>> 0 [main] sh 3472 child_info_fo
On 11/30/2012 5:24 PM, Techie Help wrote:
I have set up a new PC and installed cygwin on it.
Its windows 7 pro.
Whenever I try to build our application on it, I get the following error:
0 [main] sh 3472 child_info_fork::abort: can't commit memory for stack
0x28A000(90112), Win32 error 487
/b
Very same problem, already discussed in another thead or two.
I will also be grateful if this could be fixed.
Massi
2012/11/30 Techie Help :
> I have set up a new PC and installed cygwin on it.
> Its windows 7 pro.
>
> Whenever I try to build our application on it, I get the following error:
>
>
On 01 February 2007 16:54, Song, Conrad W wrote:
> it turns out that
> I had added UNC (\\ style windows) paths to my system PATH environment
> variable. The removal of these (maybe slow network drives) from the PATH
> (or disconnection from the network) solved the problem for me. Perhaps
> furt
> But Cygwin's should work fine, and if it means saving a bazillion 1-byte
> syscalls then I think bash should be patched to remove this sillyness
> ASAP.
I get the hint! Look for a new release of bash in the near future; and
once I get the cygport build going, I will also try to get the bash-3.2
On Fri, Sep 01, 2006 at 05:07:49PM -0500, Gary R. Van Sickle wrote:
>> From: Christopher Faylor
>> Sent: Friday, September 01, 2006 1:01 PM
>> Subject: Re: cygwin fork()
>>
>> On Fri, Sep 01, 2006 at 06:57:10PM +0100, Dave Korn wrote:
>> >On 01 September 200
Brian Dessent wrote:
"Gary R. Van Sickle" wrote:
AFAIK, Cygwin's lseek should handle seeking on text streams.
DJ implemented that years ago.
Last I looked, which was admittedly also years ago, it was "#if 0"'ed out,
with a comment to the effect of "Nobody has any business seeking around in
text
"Gary R. Van Sickle" wrote:
> > AFAIK, Cygwin's lseek should handle seeking on text streams.
> > DJ implemented that years ago.
>
> Last I looked, which was admittedly also years ago, it was "#if 0"'ed out,
> with a comment to the effect of "Nobody has any business seeking around in
> text files.
> From: Christopher Faylor
> Sent: Friday, September 01, 2006 1:01 PM
> Subject: Re: cygwin fork()
>
> On Fri, Sep 01, 2006 at 06:57:10PM +0100, Dave Korn wrote:
> >On 01 September 2006 18:47, clayne wrote:
> >>I found the real culprit, which I had also ifdef'
On Fri, Sep 01, 2006 at 06:57:10PM +0100, Dave Korn wrote:
>On 01 September 2006 18:47, [EMAIL PROTECTED] wrote:
>>I found the real culprit, which I had also ifdef'd out because it looked
>>bogus and crufty:
>>
>>/* Return 1 if a seek on FD will succeed. */
>>#ifndef __CYGWIN__
>># define fd_is_se
On 01 September 2006 18:47, [EMAIL PROTECTED] wrote:
> I found the real culprit, which I had also ifdef'd out because it looked
> bogus and crufty:
>
> /* Return 1 if a seek on FD will succeed. */
> #ifndef __CYGWIN__
> # define fd_is_seekable(fd) (lseek ((fd), 0L, SEEK_CUR) >= 0)
> #else
> #
I'm just changing the subject so that Eric will, with luck, notice
and comment on what's going on here.
cgf
On Fri, Sep 01, 2006 at 10:47:13AM -0700, [EMAIL PROTECTED] wrote:
>On Fri, Sep 01, 2006 at 01:24:57PM -0400, Christopher Faylor wrote:
>> >In regards to setting the fd to textmode as a way
On Fri, Sep 01, 2006 at 01:24:57PM -0400, Christopher Faylor wrote:
> >In regards to setting the fd to textmode as a way of stripping CRs.
> >Only problem is that it's making 213,110 syscalls for a 213k libtool
> >script. That cannot be an efficient way to remove CRs from input.
>
> Opening a fil
On Fri, Sep 01, 2006 at 10:04:51AM -0700, [EMAIL PROTECTED] wrote:
>On Fri, Sep 01, 2006 at 09:34:15AM -0700, [EMAIL PROTECTED] wrote:
>> BTW:
>> I started up filemon to watch what was going on from it's standpoint, and it
>> shows a huge number of READs on libtool, all SUCCESS, but the offset is
On Fri, Sep 01, 2006 at 10:04:51AM -0700, [EMAIL PROTECTED] wrote:
> I've since removed the setmode() calls within a bash build and am testing now.
>
> UPDATE:
> SOLVED.
>
> Filemon now shows bash reading in 8k chunks. There is now no 3 second delay on
> reading the rest of the bash script (which
On Fri, Sep 01, 2006 at 09:34:15AM -0700, [EMAIL PROTECTED] wrote:
> BTW:
> I started up filemon to watch what was going on from it's standpoint, and it
> shows a huge number of READs on libtool, all SUCCESS, but the offset is always
> 1 higher than previous, with a length of 1. Like it's literally
On Fri, 1 Sep 2006, Christopher Faylor wrote:
> On Fri, Sep 01, 2006 at 08:37:09AM -0700, [EMAIL PROTECTED] wrote:
> >On Fri, Sep 01, 2006 at 10:33:47AM -0400, Igor Peshansky wrote:
> >> While Cygwin is an *emulation* layer, and emulation is inherently
> >> slower than straight execution, there ar
On Fri, Sep 01, 2006 at 09:09:11AM -0700, [EMAIL PROTECTED] wrote:
> On Fri, Sep 01, 2006 at 11:54:03AM -0400, Christopher Faylor wrote:
> > >It's definitely none of those as I don't run any firewall or antivirus
> > >software whatsoever on this box. Windows 2003 Server, minimal set of
> > >service
On Fri, Sep 01, 2006 at 11:54:03AM -0400, Christopher Faylor wrote:
> >It's definitely none of those as I don't run any firewall or antivirus
> >software whatsoever on this box. Windows 2003 Server, minimal set of
> >services. The machine literally sits at 0% CPU unless I'm using it.
>
> Try using
On Fri, Sep 01, 2006 at 08:37:09AM -0700, [EMAIL PROTECTED] wrote:
>On Fri, Sep 01, 2006 at 10:33:47AM -0400, Igor Peshansky wrote:
>> While Cygwin is an *emulation* layer, and emulation is inherently slower
>> than straight execution, there are other potential reasons for the
>> slowness. Check y
On Fri, Sep 01, 2006 at 08:37:09AM -0700, [EMAIL PROTECTED] wrote:
>
> 1157123322 + echo blah1
> 1157123322 blah1
> <3 seconds of doing absolutely nothing here>
> 1157123325 + test -z ''
> 1157123325 + echo blah2
> 1157123325 blah2
I just also copied the same libtool to 3 different hard drives, o
On Fri, Sep 01, 2006 at 10:33:47AM -0400, Igor Peshansky wrote:
> While Cygwin is an *emulation* layer, and emulation is inherently slower
> than straight execution, there are other potential reasons for the
> slowness. Check your anti-virus and firewall software settings. If
> possible, exclude
On Fri, 1 Sep 2006, clayne wrote:
> On Fri, Sep 01, 2006 at 11:12:59AM +0100, Dave Korn wrote:
> > On 01 September 2006 11:02, [EMAIL PROTECTED] wrote:
> >
> > > Is it just me or is cygwin fork(), or a support syscall underneath,
> > > terribly slow for some reason?
> >
> > Some reason == "lack
On Fri, 1 Sep 2006, clayne wrote:
> Is it just me or is cygwin fork(), or a support syscall underneath,
> terribly slow for some reason? While building projects using libtool
> (which using heavy sh, hence fork() calls) I regularly have to fire off
> 'make -j16's just to get around waiting ages wh
On Fri, Sep 01, 2006 at 11:12:59AM +0100, Dave Korn wrote:
> On 01 September 2006 11:02, [EMAIL PROTECTED] wrote:
>
> > Is it just me or is cygwin fork(), or a support syscall underneath,
> > terribly slow for some reason?
>
> Some reason == "lack of O/S support".
Basically, this is what I'm
On 01 September 2006 11:22, [EMAIL PROTECTED] wrote:
> On Fri, Sep 01, 2006 at 11:12:59AM +0100, Dave Korn wrote:
>>> Is it just me or is cygwin fork(), or a support syscall underneath,
>>> terribly slow for some reason?
>>
>> Some reason == "lack of O/S support".
>
> Yes I can understand that
On Fri, Sep 01, 2006 at 11:12:59AM +0100, Dave Korn wrote:
> > Is it just me or is cygwin fork(), or a support syscall underneath,
> > terribly slow for some reason?
>
> Some reason == "lack of O/S support".
Yes I can understand that. I'm assuming there is some CreateProcess()
magic happening
On 01 September 2006 11:02, [EMAIL PROTECTED] wrote:
> Is it just me or is cygwin fork(), or a support syscall underneath,
> terribly slow for some reason?
Some reason == "lack of O/S support".
cheers,
DaveK
--
Can't think of a witty .sigline today
--
Unsubscribe info:
Brian Dessent wrote:
Linda W wrote:
Windows just doesn't support forking at all, as far as I know.
activeperl emulates forking using win32 threads. I don'tknow how cygwin
handles it, but my guess is that it's not very well :-(
This smells like total FUD. This person that admittedly
On Tue, Jun 06, 2006 at 01:30:43PM -0700, Linda W wrote:
> A problem I reported in trying to install "File::BOM" (module to handle
> files with Unicode Byte-Order-Marks) under CPAN originally here:
> http://sourceware.org/ml/cygwin/2006-02/msg00238.html last February
> is still a problem. I bounc
Linda W wrote:
> Windows just doesn't support forking at all, as far as I know.
> activeperl emulates forking using win32 threads. I don'tknow how cygwin
> handles it, but my guess is that it's not very well :-(
This smells like total FUD. This person that admittedly does not use
Cygwin nor obvi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Sudhahar on 2/6/2006 5:33 AM:
> Hi,
>In Cygwin fork code the statement
>
> int res = setjmp (grouped.ch.jmp);
> if (res)
> res = fork_child (grouped.ch.parent, grouped.first_dll,
> grouped.load_dlls);
> else
> res = fork_
On 11/23/2005, David Svoboda wrote:
My best guess is that this bug was introduced by a new version of
cygwin, as it did not occur until I did a cygwin-update.
But didn't you claim that switching back to an older version of Cygwin
didn't help?
It seems that the oldest cygwin I can get is 1.5
Larry Hall (Cygwin) wrote:
[EMAIL PROTECTED] wrote:
On Saturday 19 November 2005 01:07 am, Larry Hall (Cygwin) wrote:
David Svoboda wrote:
I have built a C++ server program called 'analyzer'. But when I try to
run it, it fails upon trying to execute a 'fork' command. Why?
If runn
[EMAIL PROTECTED] wrote:
On Saturday 19 November 2005 01:07 am, Larry Hall (Cygwin) wrote:
David Svoboda wrote:
I have built a C++ server program called 'analyzer'. But when I try to
run it, it fails upon trying to execute a 'fork' command. Why?
If running 'rebaseall' doesn't help (se
On Saturday 19 November 2005 01:07 am, Larry Hall (Cygwin) wrote:
> David Svoboda wrote:
> > I have built a C++ server program called 'analyzer'. But when I try to
> > run it, it fails upon trying to execute a 'fork' command. Why?
> >
> >
> >$ analyzer --KANTOO_LANGUAGE=toy -server-multiple -fo
David Svoboda wrote:
I have built a C++ server program called 'analyzer'. But when I try to
run it, it fails upon trying to execute a 'fork' command. Why?
$ analyzer --KANTOO_LANGUAGE=toy -server-multiple -fork
Analyzer 2.0
*** 5 [main] analyzer 1712
fhandler_disk_file::fixup_mmap_a
Chris,
On Sat, Dec 22, 2001 at 10:22:37AM -0500, Chris McDonough wrote:
> FYI, Zope was broken under out-of-the-box Cygwin 1.3.6 because of the fork
> issue. The rebase solution allows Zope to work again.
>
> Many thanks,
You are very welcome! Thanks for taking the time to see if this solutio
y, December 21, 2001 7:51 AM
Subject: Re: cygwin fork() rebase solution (was Re:
dll_list::load_after_fork() blues ...)
> Chris,
>
> On Tue, Dec 18, 2001 at 10:28:13PM -0500, Christopher Faylor wrote:
> > On Wed, Dec 19, 2001 at 08:33:50AM +1100, Robert Collins wrote:
> >
Chris,
On Tue, Dec 18, 2001 at 10:28:13PM -0500, Christopher Faylor wrote:
> On Wed, Dec 19, 2001 at 08:33:50AM +1100, Robert Collins wrote:
> >Your results are enough for me Jason - I'm happy to include this in
> >setup in some form.
>
> Nice job, Jason. Thanks for following this through.
You
Jason Tishler writes:
>
>I believe that I have found a rebase solution to the Cygwin fork()
>problem that has been causing Cygwin Python some grief lately. I added
>an offset option to the attached rebase tool. If I spread the DLLs out
>by an extra 0x1, then the fork() problem seems to be mi
On Wed, Dec 19, 2001 at 08:33:50AM +1100, Robert Collins wrote:
>Your results are enough for me Jason - I'm happy to include this in
>setup in some form.
Nice job, Jason. Thanks for following this through.
cgf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:
Your results are enough for me Jason - I'm happy to include this in
setup in some form.
Rob
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygw
47 matches
Mail list logo
