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
>
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 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
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
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_fork::abort:
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 techiei...@yahoo.co.uk:
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
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
further
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:
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 behind
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. I'm assuming
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 talking
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 when
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 of O/S support.
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, 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, one
even
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
services. The
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 are other
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, 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 I
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 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 file with
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 of
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
# define
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_seekable(fd)
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'd out because it
looked bogus and crufty
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.
FWIW,
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
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 2006 18:47, clayne wrote:
I found the real culprit
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
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
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 bounced it
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
-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_parent
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?
snip
If
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
[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?
snip
If running 'rebaseall' doesn't
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 -fork
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
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 solution
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:
Your results are enough for me Jason - I'm happy to include
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
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:
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:
43 matches
Mail list logo
