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,
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 wa
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 cha
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 n
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) sp
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 DE
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:
#! /b
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 Cygw
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
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
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
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 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
13 matches
Mail list logo
