RE: X11 forwarding extremely slow (unusable) after Cygwin upgrade on Dec 23rd
The problem is with cygwin 3.1.0-1, released on Dec 16th, or thereabouts. I decided to track it down by re-installing the earlier working release from the Cygwin time machine at crouchingtigerhiddenfruitbat.org, and then incrementally upgrading it until the problem showed up. It turns out that it was introduced in the Dec 16th release, which made just one change - upgraded cygwin from 3.0.7-1 to 3.1.0-1. With the Dec 15th release all works fine - nice fast response in the X11 windows, with the Dec 16th release the same programs in X11 windows are really, really slow. I can roll cygwin back to 3.0.7-1 from the latter release and X.11 then works fine again. To quantify the problem, I timed these using the BeyondCompare and kdiff3 file diff programs (which really show up the issue being very CPU intensive) comparing two versions of a source code directory containing 6 largish files, all differing: Time to open the window and display the directory: BeyondCompare with cygwin 3.0.7-1: 2 seconds, with cygwin 3.1.0-1: 18 seconds. Kdiff3 with cygwin 3.0.7.1: 4 seconds with cygwin 3.1.0-1: 15 seconds. Time to open a tab and display the diffs for one of the files: BeyondCompare with cygwin 3.0.7-1: 1 seconds, with cygwin 3.1.0-1: 8 seconds. Kdiff3 with cygwin 3.0.7.1: 5 seconds with cygwin 3.1.0-1: 13 seconds. Firefox is not so bad, but still slower. The time to open the window and display the default home page is about 2 seconds with cygwin 3.0.7-1, 5 seconds with 3.1.0-1. And the problem that I reported below relating to slow response trying to type into Firefox's address bar is not showing up with this build. Either that was introduced later, or maybe it was some side effect of the upgrade path that I took then? Ian > -Original Message- > From: cygwin-ow...@cygwin.com On Behalf > Of Ian Puleston > Sent: Friday, December 27, 2019 4:39 PM > To: cygwin@cygwin.com > Subject: X11 forwarding extremely slow (unusable) after Cygwin upgrade on > Dec 23rd > > Hi, > > I have a Cygwin installation on a Windows 10 PC, on which I use X-Windows > to access a Linux development/build server. All has been working great for a > long time, until I rand a Cygwin upgrade on December 23rd, and after that > X11 has become pretty much unusable. I normally launch the terminator > terminal emulator locally under X, in that I "ssh -Y" to the Linux machine, and > then on there I use a number of GUI apps, mainly SlickEdit and > BeyondCompare, which run remotely via X11 forwarding to display in > windows on my local Windows PC. But since this Cygwin upgrade all of those > remote X11 apps are now extremely slow to respond to anything - about 10 > to 20 seconds to action any key press or mouse click. > > The two machines are on the same Gig-Ethernet LAN segment so there are > no latency issues there (ping response time <1mS). > > To take any possible problems with those components out of the picture, I > tried instead launching xterm under X11 locally, and from it launching Firefox > after ssh to the Linux machine, and again I see the same symptoms with that > - trying to type into Firefox's address bar takes about 10 seconds per letter. > > I had previously updated my Cygwin installation on March 3rd 2019, so this > problem has come in sometime between then and now. I've just spent a very > long day and a half rolling back the changes as much as I could (by hacking > the setup.ini and re-installing previous versions from the local download > cache) and eventually managed to get a working hybrid with enough > packages rolled back to make the difference, and now X11 is working fine > again. > > I also tried a new clean install of the latest Cygwin, after deleting my .XWinrc > and removing all but the bare minimum from .startxwinrc, and do see the > problem with that too. > > Is this any known problem? I couldn't find anything obvious in the email > archives. > > Ian > > -- > 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: [ANNOUNCEMENT] Updated: setup (2.898)
On Sat, Dec 28, 2019 at 8:40 AM Jon Turney wrote: > > > A new version of Setup (2.898) has been uploaded to: > >https://cygwin.com/setup-x86_64.exe (64 bit version) >https://cygwin.com/setup-x86.exe (32 bit version) Something definitely busted in this version for me. I've been using the same command line to download an offline, partial mirror for more than 5 years: setup-x86_64.exe --disable-buggy-antivirus --download --no-desktop --root "%CD%\Temp" --quiet-mode --categories All --remove-categories Debug --local-package-dir "%CD%" --site "%MIRROR%" On a clean directory structure, this now stops executing without downloading anything: Starting cygwin install, version 2.898 User has backup/restore rights io_stream_cygfile: fopen(/etc/setup/setup.rc) failed 2 No such file or directory Current Directory: V:\Installers\Cygwin\x64 Could not open service McShield for query, start and stop. McAfee may not be installed, or we don't have access. Selected local directory: V:\Installers\Cygwin\x64 net: Preconfig site: http://mirrors.koehn.com/cygwin/cygwin-ftp/ HTTP status 404 fetching http://mirrors.koehn.com/cygwin/cygwin-ftp/x86_64/setup.zst.sig HTTP status 404 fetching http://mirrors.koehn.com/cygwin/cygwin-ftp/x86_64/setup.zst io_stream_cygfile: fopen(/etc/setup/timestamp) failed 2 No such file or directory io_stream_cygfile: fopen(/etc/setup/installed.db) failed 2 No such file or directory solving: 11308 tasks, update: no, use test packages: no -- 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
output of ls / grep corrupted in cygwin 3.1.2-1 (x64) under conemu
Hello I am running win10 Pro 1903 x64. After update to cygwin 3.1.2-1 for the x64 Version the command "ls-l" misses the running in Conemu. There is a for every new line, but the new line starts in position where the line before finished, just 1 line deeper. This is true using cygwin in the conemu version 191012 and also cmder and cmdermini. If I start a plain MS console cmd.exe the output looks good. The error also occoures for grep command. Others I did not test. I tested also cygwin 3.1.2-1 under win7 Pro. Here everything works in cygwin 32 bit and 64 bit. Installing previous version cygwin 3.0.7-1 shows correct output for conemu, cmder and cmd.exe. Any help appreciated. Hartmut -- 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: output of ls / grep corrupted in cygwin 3.1.2-1 (x64) under conemu
On Wed, 1 Jan 2020 15:55:15 +0100 Hartmut Bartels wrote: > Hello > I am running win10 Pro 1903 x64. > After update to cygwin 3.1.2-1 for the x64 Version > the command "ls-l" misses the running in Conemu. > There is a for every new line, but the new line starts in position > where the line before finished, just 1 line deeper. This is true using > cygwin in the conemu version 191012 and also cmder and cmdermini. > If I start a plain MS console cmd.exe the output looks good. > The error also occoures for grep command. Others I did not test. > > I tested also cygwin 3.1.2-1 under win7 Pro. Here everything works in > cygwin 32 bit and 64 bit. > > > Installing previous version cygwin 3.0.7-1 shows correct output > for conemu, cmder and cmd.exe. > > Any help appreciated. This is because ConEmu does not support DISABLE_NEWLINE_AUTO_RETURN. Cygwin 3.1.2-1 uses this feature which is supported by command prompt on Win10 1703 or later. See https://github.com/Maximus5/ConEmu/issues/1966 and comment on line 1188 in https://github.com/Maximus5/ConEmu/blob/master/src/ConEmuHk/Ansi.cpp -- Takashi Yano -- 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: [ANNOUNCEMENT] Updated: setup (2.898)
On 01/01/2020 13:27, Bryan Berns wrote: On Sat, Dec 28, 2019 at 8:40 AM Jon Turney wrote: A new version of Setup (2.898) has been uploaded to: https://cygwin.com/setup-x86_64.exe (64 bit version) https://cygwin.com/setup-x86.exe (32 bit version) Something definitely busted in this version for me. I've been using the same command line to download an offline, partial mirror for more than 5 years: setup-x86_64.exe --disable-buggy-antivirus --download --no-desktop --root "%CD%\Temp" --quiet-mode --categories All --remove-categories Debug --local-package-dir "%CD%" --site "%MIRROR%" On a clean directory structure, this now stops executing without downloading anything: Thanks for reporting this problem, and for providing the command line to reproduce it. This seems to be a crash which occurs when a package which only has a test version and no current version is selected via the command line (so using '--categories All' will hit the few packages which are instances of this) I've built setup with a patch which attempts to address this: https://cygwin.com/setup/setup-2.899.x86_64.exe https://cygwin.com/setup/setup-2.899.x86.exe Perhaps you could try that and see if it improves things for you? -- 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
subversion-1.11.1-1+libserf1_0-1.3.9-1: Segfault after failed connect + empty serf debug package
Subversion segfaults with null instruction pointer after a failed connect. This affects the http and https protocols but not the svn protocol. Related report: https://cygwin.com/ml/cygwin/2019-11/msg00126.html Testcase: $ uname -srvmo CYGWIN_NT-10.0 3.1.2(0.340/5/3) 2019-12-21 15:25 x86_64 Cygwin $ cygcheck -f /bin/svn subversion-1.11.1-1 $ cygcheck -f /bin/cygserf-1-0.dll libserf1_0-1.3.9-1 $ svn info https://127.0.0.1:49494 Segmentation fault (core dumped) $ svn info http://127.0.0.1:49494 Segmentation fault (core dumped) $ svn info svn://127.0.0.1:49494 svn: E170013: Unable to connect to a repository at URL 'svn://127.0.0.1:49494' svn: E000111: Can't connect to host '127.0.0.1': Connection refused Stacktrace from gdb: #0 0x in ?? () #1 0x0003ce7c2c87 in serf.process_connection () from /usr/bin/cygserf-1-0.dll #2 0x0003ce7c1333 in serf_event_trigger () from /usr/bin/cygserf-1-0.dll #3 0x0003ce7c141c in serf_context_run () from /usr/bin/cygserf-1-0.dll #4 0x0003ce0e7a11 in svn_ra_serf__context_run (sess=0x8000c2fb8, waittime_left=0xbef0, scratch_pool=0x8000d7e38) at /usr/src/debug/subversion-1.11.1-1/subversion/libsvn_ra_serf/util.c:913 ... Is possibly some error handling function pointer not set properly? Same problem applies to cygwin x86 version. Downgrading to cygwin-3.0.7-1, libserf1_0-1.3.8-1 and subversion-1.10.4-1 does not help. There is no easy way for further debugging. A serf-debuginfo package exists, but its tarball is empty... PS: On the mirrors, there is still a serf-1.2.1-1-src.tar.bz2 with a (nonempty!) serf-debuginfo-1.2.1-1.tar.bz2 but the corresponding binary package libserf1_0-1.2.1-1.tar.xz is missing. -- 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 parenting issue
I have a project that involves starting a number of programs in the background and then monitoring and reporting when they terminate. My approach has been to write a small application called 'parent' that loops on waitpid() until there are no more children. I invoke it in a script like: #! /bin/bash program1 & program2 & program3 & exec parent This of course works under Linux, but under Cygwin, although 'ps' documents the parent/child relationship, waitpid() immediately returns ECHILD, indicating there are no child processes. If I use the shell's waitpid, that works alright, so I am wondering whether the problem is a casualty of the exec. I have a minimal test setup at https://github.com/nthallen/test_parenting, along with examples showing how it works under Linux and Cygwin. Is this something that we would expect to work under Cygwin? -Norton -- 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 parenting issue
Hi Norton, I've only just grabbed the cygwin source code very recently out of desperation to try to solve a different problem that I'm experiencing, so I'm definitely no expert. However, in the source is a file called "how-spawn-works.txt", which does have a disclaimer at the top: (THIS DESCRIPTION IS OUT-OF-DATE) However, what it does say is: * if the mode is _P_OVERLAY (we are doing an exec) wait for the child to a) if it's a cygwin process, signal us via an event. b) if it's a win32 process, exit. c) exit. And, from what I can tell, that's what the new code still does. i.e. it is a new process being created, because the Windows API doesn't have an equivalent to the POSIX exec() type functionality. So... your executed programme (i.e. parent) is not simply replacing the bash executable within the same Windows process - it is actually inside a child process. Having said that, given that cygwin manages its own pids, I think it should be able to simulate the waitpid() functionality within the concept of an exec. For example, I did notice this bit of code: cygpid = (mode != _P_OVERLAY) ? create_cygwin_pid () : myself->pid; So clearly it is trying to preserve the same pid. I'd have to dig much deeper into the code to try to work out why waitpid() is not doing what you want, but perhaps there is someone else who already has that knowledge ? Dave On 2/01/2020 08:01, Norton Allen wrote: I have a project that involves starting a number of programs in the background and then monitoring and reporting when they terminate. My approach has been to write a small application called 'parent' that loops on waitpid() until there are no more children. I invoke it in a script like: #! /bin/bash program1 & program2 & program3 & exec parent This of course works under Linux, but under Cygwin, although 'ps' documents the parent/child relationship, waitpid() immediately returns ECHILD, indicating there are no child processes. If I use the shell's waitpid, that works alright, so I am wondering whether the problem is a casualty of the exec. -- 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: Resource temporarily unavailable errors after upgrading cygwin packages
Hi Ken, Thanks for having a look at my issue. On 1/01/2020 06:20, Ken Brown wrote: On 12/30/2019 6:10 PM, David Finnie wrote: I recently upgraded my cygwin64 installation to get latest packages. After the install, if I run a fairly lengthy GNU make with multiple concurrent jobs (-j option) specified, some of the sub-makes fail with "Resource temporarily unavailable" errors. In all cases, this has been when make is starting a shell (i.e. $(shell ...) ) to help with setting up some of the variables required in the make processing. The failure, however, occurs in different places in the make files used (the make spawns several sub-makes). Does this happen with every parallel make, or is it one specific program that you're building? If the latter, can you give a detailed recipe so that others can try to reproduce the problem? It's happening consistently across a bunch of libraries and executables that I build (with a series of invocations of make). While each of those builds has their own Makefile, each of them includes a common set of makefiles that does the vast majority of the work, so I guess you could say that it really is just isolated (as far as I can tell), to one build environment. The build is not of open source software - it is for software created by the company I work for, so unfortunately I can't share all of the source code etc., but I can certainly give details of what we're doing. The make builds a cross-platform set of products, and so invokes both Windows native compilers, and also cross compilers for the other platforms (Linux, and HPE NonStop). So there are many tools being invoked simultaneously. Keep in mind, though, that this has been working perfectly for me for over a decade. I will say that I did run into the need to run rebase after upgrading cygwin many years ago, but that fixed the issue for me immediately. Not so this time, and there has been nothing else changed in my environment. I actually ran the build successfully just minutes before upgrading the cygwin packages, and then it failed immediately after that. I have not tried building for any other product. I might try that. Have you tried reverting to cygwin-3.0.7-1? No, I haven't - I'll try that now. Thanks. The only thing that jumps out at me from your cygcheck output is that your PATH is very long. I don't know if that's relevant, but you might try cutting it down before running make. I did try changing PATH to a much smaller value (/bin:/usr/bin:/usr/local/bin) but I still got exactly the same behaviour :-( A good thing to try, though. I'll see how I go after downgrading cygwin. Thanks again. Dave -- 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 parenting issue
On 1/1/2020 4:01 PM, Norton Allen wrote: > I have a project that involves starting a number of programs in the > background > and then monitoring and reporting when they terminate. My approach has been > to > write a small application called 'parent' that loops on waitpid() until there > are no more children. I invoke it in a script like: > > #! /bin/bash > program1 & > program2 & > program3 & > exec parent > > This of course works under Linux, but under Cygwin, although 'ps' documents > the > parent/child relationship, waitpid() immediately returns ECHILD, indicating > there are no child processes. If I use the shell's waitpid, that works > alright, > so I am wondering whether the problem is a casualty of the exec. > > I have a minimal test setup at https://github.com/nthallen/test_parenting, > along > with examples showing how it works under Linux and Cygwin. This looks like the issue that was reported here: https://cygwin.com/ml/cygwin/2019-09/msg00263.html It's been fixed. Try updating the cygwin package. $ uname -a CYGWIN_NT-10.0 moufang2 3.1.2(0.340/5/3) 2019-12-29 17:28 x86_64 Cygwin $ ./parent_test2.sh Parent pid is 24159 Child pid is 24161 UID PIDPPID TTYSTIME COMMAND kbrown 24159 24158 pty4 18:07:48 /usr/bin/bash kbrown 24162 24159 pty4 18:07:48 /usr/bin/ps kbrown 24161 24159 pty4 18:07:48 /usr/bin/sleep Parent PID is 24159 UID PIDPPID TTYSTIME COMMAND kbrown 24159 24158 pty4 18:07:48 /tmp/test_parenting/parent_test kbrown 24161 24159 pty4 18:07:48 /usr/bin/sleep Process 24161 terminated: status No more children Ken -- 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: Resource temporarily unavailable errors after upgrading cygwin packages
Hi all,
I did as Ken suggested and reverted to 3.0.7-1. (Thanks, Ken !)
That has fixed the issue for me, and the make it now running again at
full speed. I forgot to mention that it did seem somewhat slower with
the new version of cygwin.
That strongly implies that there is an issue with changes made since
then. I noticed that in fork.cc, at line 540, this new code exists:
/* Do not attach to the child before it has successfully initialized.
Otherwise we may wait forever, or deliver an orphan SIGCHILD. */
if (!child.reattach ())
{
this_errno = EAGAIN;
#ifdef DEBUGGING0
error ("child reattach failed");
#endif
goto cleanup;
}
Since I am getting "Resource temporarily unavailable", which equates to
EAGAIN, and this code is new, this looks like the most likely candidate
to investigate first (but rest assured that I'm not saying that this
code is definitely the culprit !).
The reattach and parent/child logic looks reasonably complex and I've
only just downloaded the code, so I'm not sure that I want to try fixing
anything for fear of breaking much more.
Could someone please scan an eye over this code ? I noticed that there
were 2 commits related to this - moving the reattach() until later
processing. Is it possible that there is still an opportunity that the
reattach() fails even when things are working properly ?
Thanks.
Dave
On 2/01/2020 09:32, David Finnie wrote:
Hi Ken,
Thanks for having a look at my issue.
On 1/01/2020 06:20, Ken Brown wrote:
On 12/30/2019 6:10 PM, David Finnie wrote:
I recently upgraded my cygwin64 installation to get latest packages.
After the install, if I run a fairly lengthy GNU make with multiple
concurrent
jobs (-j option) specified, some of the sub-makes fail with "Resource
temporarily unavailable" errors. In all cases, this has been when
make is
starting a shell (i.e. $(shell ...) ) to help with setting up some
of the
variables required in the make processing. The failure, however,
occurs in
different places in the make files used (the make spawns several
sub-makes).
Does this happen with every parallel make, or is it one specific
program that
you're building? If the latter, can you give a detailed recipe so
that others
can try to reproduce the problem?
It's happening consistently across a bunch of libraries and
executables that I build (with a series of invocations of make). While
each of those builds has their own Makefile, each of them includes a
common set of makefiles that does the vast majority of the work, so I
guess you could say that it really is just isolated (as far as I can
tell), to one build environment. The build is not of open source
software - it is for software created by the company I work for, so
unfortunately I can't share all of the source code etc., but I can
certainly give details of what we're doing.
The make builds a cross-platform set of products, and so invokes both
Windows native compilers, and also cross compilers for the other
platforms (Linux, and HPE NonStop). So there are many tools being
invoked simultaneously.
Keep in mind, though, that this has been working perfectly for me for
over a decade. I will say that I did run into the need to run rebase
after upgrading cygwin many years ago, but that fixed the issue for me
immediately. Not so this time, and there has been nothing else changed
in my environment. I actually ran the build successfully just minutes
before upgrading the cygwin packages, and then it failed immediately
after that.
I have not tried building for any other product. I might try that.
Have you tried reverting to cygwin-3.0.7-1?
No, I haven't - I'll try that now. Thanks.
The only thing that jumps out at me from your cygcheck output is that
your PATH
is very long. I don't know if that's relevant, but you might try
cutting it
down before running make.
I did try changing PATH to a much smaller value
(/bin:/usr/bin:/usr/local/bin) but I still got exactly the same
behaviour :-( A good thing to try, though.
I'll see how I go after downgrading cygwin.
Thanks again.
Dave
--
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 parenting issue
On 1/1/2020 6:24 PM, Ken Brown wrote: This looks like the issue that was reported here: https://cygwin.com/ml/cygwin/2019-09/msg00263.html It's been fixed. Try updating the cygwin package. That is awesome! Thanks for testing and confirming (as I have just done as well.) Here I thought I was up to date... -Norton -- 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: Resource temporarily unavailable errors after upgrading cygwin packages
On 1/1/2020 6:43 PM, David Finnie wrote:
> That strongly implies that there is an issue with changes made since then. I
> noticed that in fork.cc, at line 540, this new code exists:
>
> /* Do not attach to the child before it has successfully initialized.
> Otherwise we may wait forever, or deliver an orphan SIGCHILD. */
> if (!child.reattach ())
> {
> this_errno = EAGAIN;
> #ifdef DEBUGGING0
> error ("child reattach failed");
> #endif
> goto cleanup;
> }
>
> Since I am getting "Resource temporarily unavailable", which equates to
> EAGAIN,
> and this code is new, this looks like the most likely candidate to
> investigate
> first (but rest assured that I'm not saying that this code is definitely the
> culprit !).
You could try building cygwin with DEBUGGING0 defined to see if this is where
the EAGAIN is coming from. I think the error message would show up in strace
output, so you'd have to be able to reproduce the problem under strace.
And it would be great if you could find a testcase that you can share with the
list, so that others can try to reproduce the problem.
Ken
--
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
