up here:
>
> when building ruby with a high -j value (I'm doing make -j21), I get
> errors of the sort:
> 0 [main] miniruby 9272 fhandler_dev_zero::fixup_mmap_after_fork:
> requested 0x6FFFE6A6 != 0x0 mem alloc base 0x0, state 0x1, size
> 17545331867648, Win32 err
On Tue, 21 Jan 2025, Jeremy Drake via Cygwin wrote:
> I did not see this happen with ruby 3.3.7, or when building with -j1.
Sorry, spoke too soon, I did see this immediately with 3.3.7 as well.
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/fa
I've been trying to track down why ruby 3.4.1 is failing to build for
msys2. I've now confirmed that this same issue reproduces with
upstream Cygwin 3.5.4 and 3.6.0-0.335.gb879cd1661ad, so I thought I'd
bring it up here:
when building ruby with a high -j value (I'm doing make
> $ head openssl-1.0.2p/include/openssl/des.h
> /* crypto/des/des.h */
> /* Copyright (C) 1995-1997 Eric Young (e...@cryptsoft.com)
> * All rights reserved.
where Cygwin _has_ followed the symlink.
In emacs, the symlink in question looks like Unicode:
> !
the "good" system, the same command goes more like this:
> > $ head openssl-1.0.2p/include/openssl/des.h
> > /* crypto/des/des.h */
> > /* Copyright (C) 1995-1997 Eric Young (e...@cryptsoft.com)
> > * All rights reserved.
> where Cygwin _has_ followed the symlink
On 2024-04-19 15:39, René Berber via Cygwin wrote:
On 4/19/2024 2:59 PM, Arnab Paul via Cygwin wrote:
Hello,
I am trying to install a software which requires the libraries gcc-fortran,
make, libarpack-devel, liblapack-devel, libnetcdf-fortran-devel, git.
As I did and ran the commands given
On 4/19/2024 2:59 PM, Arnab Paul via Cygwin wrote:
Hello,
I am trying to install a software which requires the libraries gcc-fortran,
make, libarpack-devel, liblapack-devel, libnetcdf-fortran-devel, git.
As I did and ran the commands given below,
git clone https://github.com/Aida-Alvera/DINEOF
Hello,
I am trying to install a software which requires the libraries gcc-fortran,
make, libarpack-devel, liblapack-devel, libnetcdf-fortran-devel, git.
As I did and ran the commands given below,
git clone https://github.com/Aida-Alvera/DINEOF
cd DINEOF/
cp config.mk.template config.mk
make
The
; >> (see https://cygwin.com/pipermail/cygwin/2024-February/255308.html) to
> >> 3.5.0-1, I now get spurious "error 127" messages from (Cygwin's copy of)
> >> GNU make 4.4.1-2, when it starts external processes and those external
> >> processes exit wi
>> 3.5.0-1, I now get spurious "error 127" messages from (Cygwin's copy of)
>> GNU make 4.4.1-2, when it starts external processes and those external
>> processes exit with a zero exit code.
>>
>> For example, a very simple Makefile:
>>
>>
On Feb 26 17:34, Dimitry Andric via Cygwin wrote:
> Hi,
>
> After a recent upgrade of a Cygwin installation, including cygwin1.dll
> (see https://cygwin.com/pipermail/cygwin/2024-February/255308.html) to
> 3.5.0-1, I now get spurious "error 127" messages from (Cygwin'
i,
>>>> After a recent upgrade of a Cygwin installation, including cygwin1.dll
>>>> (see https://cygwin.com/pipermail/cygwin/2024-February/255308.html) to
>>>> 3.5.0-1, I now get spurious "error 127" messages from (Cygwin's copy of)
>>>> GNU mak
-February/255308.html) to
3.5.0-1, I now get spurious "error 127" messages from (Cygwin's copy of)
GNU make 4.4.1-2, when it starts external processes and those external
processes exit with a zero exit code.
For example, a very simple Makefile:
all:
cmd /c echo done
Running this a few ti
to
>> 3.5.0-1, I now get spurious "error 127" messages from (Cygwin's copy of)
>> GNU make 4.4.1-2, when it starts external processes and those external
>> processes exit with a zero exit code.
>> For example, a very simple Makefile:
>> all:
>>
On 26/02/2024 17:34, Dimitry Andric via Cygwin wrote:
Hi,
After a recent upgrade of a Cygwin installation, including cygwin1.dll
(see https://cygwin.com/pipermail/cygwin/2024-February/255308.html) to
3.5.0-1, I now get spurious "error 127" messages from (Cygwin's copy of)
GNU mak
Hi,
After a recent upgrade of a Cygwin installation, including cygwin1.dll
(see https://cygwin.com/pipermail/cygwin/2024-February/255308.html) to
3.5.0-1, I now get spurious "error 127" messages from (Cygwin's copy of)
GNU make 4.4.1-2, when it starts external processes and
Greetings, Bruce Visscher!
> As a matter of fact, perhaps I don't need winpty anymore. I used to
> have to prefix some windows console apps with this but that doesn't
> seem to be necessary now.
There have been some progress on Microsoft side regarding console behavior in
general, yes.
But in g
Brian,
On Wed, May 17, 2023 at 7:23 PM Brian Inglis wrote:
> You are definitely missing and need to install libffi8 and libgc1.
Thanks. After installing these via cygwin setup, make is working well.
In fact, the installation also corrected an issue I was having with
python. Previou
FAQ?)
You need the library libguile3.0_1 installed - we can not see if that is the
case or if there are any issues.
You also need to drop C:\Program Files\Microsoft\jdk-11.0.16.101-hotspot\bin
from your PATH, at least in Cygwin, as it looks like it is being injected into
make execution to
You need the library libguile3.0_1 installed - we can not see if that is the
> case or if there are any issues.
>
> You also need to drop C:\Program Files\Microsoft\jdk-11.0.16.101-hotspot\bin
> from your PATH, at least in Cygwin, as it looks like it is being injected into
> make executio
-hotspot\bin
from your PATH, at least in Cygwin, as it looks like it is being injected into
make execution to intercept what it is doing, but given that it is a MS JDK
hotspot, it is probably intended for some MS JDK make product, not Cygwin's, so
it will not work, and could damage something.
Trying to build the winpty package[1], I find that the make program
does not work. I have tried removing and reinstalling the package to
no avail.
> $ uname -a
> CYGWIN_NT-10.0-22621 42MF1T3 3.4.6-1.x86_64 2023-02-14 13:23 UTC x86_64 Cygwin
> $ make
> C:/cygwin64/bin/make.exe:
s+up%3A+Problems+with+parallel+make%22+site%3Ahttps%3A%2F%2Fcygwin.com%2F
>Please try the test version of the package
>https://cygwin.com/pipermail/cygwin-announce/2023-March/010972.html
>
>and let us know it the 4.4.1-2 version solves your problem
Current version of make (4.4.1-1)
On Wed, Mar 22, 2023 at 3:34 PM Jon Beniston via Cygwin wrote:
> Hi,
Hi Jon
> When trying to build gcc using make with -j N, I'm finding that make will
> hang on 64-bit Cygwin. I don't see this problem with 32-bit Cygwin on the
> same PC. When it hangs, there are N make
lso took precautions in postinstall script PATH just in case.
Just built, tested, and released curl no problem, but coreutils with make
4.4.1-1 hung up with procps, top, and bash kill, but not ls /proc/...
$ uname -srvmo
CYGWIN_NT-10.0-19044 3.5.0-0.231.g93f70d7849b8.x86_64 2023-03-07 03:11 UTC
Hi,
When trying to build gcc using make with -j N, I'm finding that make will
hang on 64-bit Cygwin. I don't see this problem with 32-bit Cygwin on the
same PC. When it hangs, there are N make processes reported in task manager
that are using 0% CPU, that appear to be waiting fo
Versions 4.4.1-1 (default) and 4.4.1-2 (test) of
make
are available in the Cygwin distribution
CYGWIN_CHANGES
The default version is built with jobserver using FIFO and
the test version using pipe.
In same complex corner case the previous 4.4-1 was reported to
fail and it is unclear if the
On 21.02.2023 14:49, Fergus Daly via Cygwin wrote:
I update my local Cygwin using setup-x86_64.exe.
The latest setup.ini file includes the lines
setup-timestamp: 1676945925
setup-version: 2.924
@ make
version: 4.4-1
[prev]
version: 4.3-1
[test]
version
I update my local Cygwin using setup-x86_64.exe.
The latest setup.ini file includes the lines
setup-timestamp: 1676945925
setup-version: 2.924
@ make
version: 4.4-1
[prev]
version: 4.3-1
[test]
version: 4.4.0.91-1
I definitely do not use the switch -t (for test
On 2023-01-19 11:38, Corinna Vinschen via Cygwin wrote:
On Jan 19 09:31, Brian Inglis via Cygwin wrote:
On 2023-01-18 02:42, Corinna Vinschen via Cygwin wrote:
I tested this yesterday with 7 runs on two machines in parallel while
building Cygwin continuously in another Window, and cygcheck stil
Corinna Vinschen, on January 19, 2023 1:39 PM wrote:
>...(had to skip 3.4.4, don't ask...)
LOL.
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml
On Jan 19 09:31, Brian Inglis via Cygwin wrote:
> On 2023-01-18 02:42, Corinna Vinschen via Cygwin wrote:
> > I tested this yesterday with 7 runs on two machines in parallel while
> > building Cygwin continuously in another Window, and cygcheck still with
> > high-entropy-VA enabled. And one of th
Which they are, due to the high-entropy stuff.
The patches are supposed to make the code less rigid in terms of the
addresses of certain memory regions, as well as dropping the
high-entropy VA flag from builds of strace and cygcheck, both of which
are loading the Cygwin DLL dynamically as part of thei
ropy stuff.
The patches are supposed to make the code less rigid in terms of the
addresses of certain memory regions, as well as dropping the
high-entropy VA flag from builds of strace and cygcheck, both of which
are loading the Cygwin DLL dynamically as part of their job.
The test release 3
ns are used by Windows itself.
> > Which they are, due to the high-entropy stuff.
> >
> > The patches are supposed to make the code less rigid in terms of the
> > addresses of certain memory regions, as well as dropping the
> > high-entropy VA flag from builds of strace and cy
7;s a non-Cygwin process which
>
> - is built with high-entropy ASLR and
>
> - tries to load the Cygwin DLL dynamically and
>
> - therefore suffers from the fact that recent Cygwin code doesn't
> expect that certain memory regions are used by Windows itself.
>
d
that the reason cygcheck fails in this way is:
- It's a non-Cygwin process which
- is built with high-entropy ASLR and
- tries to load the Cygwin DLL dynamically and
- therefore suffers from the fact that recent Cygwin code doesn't
expect that certain memory regions are used by Windows
Hi Takashi,
On Jan 16 16:18, Corinna Vinschen via Cygwin wrote:
> Actually, I' running your testcase on two machines in parallel now for
> quite some time, which only one hunk of 60675f1a7eb2 reverted, i.e.
>
> diff --git a/winsup/cygwin/mm/shared.cc b/winsup/cygwin/mm/shared.cc
> index 893b20d28
problem didn't show up once. Maybe you'd like to try the same?
After struggling to build and release a new ncurses test package yesterday, with
many hangs including unrelated hourly cron jobs, make, top, ps, and using Cygwin
/bin/ps and /bin/kill -f combos a lot to make progress, I
On 2023-01-16 08:40, Jon Turney via Cygwin wrote:
On 10/01/2023 00:00, Brian Inglis via Cygwin wrote:
On Mon, 9 Jan 2023 14:36:44 +0100, Corinna Vinschen wrote:> On Dec 29
21:59, Brian Inglis via Cygwin wrote:
I got some hangs (deadlock?) between (parallel?) make jobs, top,
procps, and even
On 10/01/2023 00:00, Brian Inglis via Cygwin wrote:
On Mon, 9 Jan 2023 14:36:44 +0100, Corinna Vinschen wrote:> On Dec 29
21:59, Brian Inglis via Cygwin wrote:
I got some hangs (deadlock?) between (parallel?) make jobs, top,
procps, and
even ls /proc/*/ when trying to cygport all check curl
Hi Takashi,
On Jan 16 23:45, Takashi Yano via Cygwin wrote:
> On Mon, 16 Jan 2023 11:23:54 +0100
> Corinna Vinschen wrote:
> > On Jan 16 18:02, Takashi Yano via Cygwin wrote:
> > [...]
> > > Errors seem to be three types: (null), cygpid.xxx and shared.5.
> > > I'm not sure what is happening and wh
On Mon, 16 Jan 2023 11:23:54 +0100
Corinna Vinschen wrote:
> On Jan 16 18:02, Takashi Yano via Cygwin wrote:
> > Hi Corinna,
> >
> > On Mon, 9 Jan 2023 14:20:56 +0100
> > Corinna Vinschen wrote:
> > > On Jan 2 17:21, Takashi Yano via Cygwin wrote:
> > > > On Mon, 2 Jan 2023 14:38:03 +0900
> > > >
On Jan 16 18:02, Takashi Yano via Cygwin wrote:
> Hi Corinna,
>
> On Mon, 9 Jan 2023 14:20:56 +0100
> Corinna Vinschen wrote:
> > On Jan 2 17:21, Takashi Yano via Cygwin wrote:
> > > On Mon, 2 Jan 2023 14:38:03 +0900
> > > Takashi Yano wrote:
> > > > On Mon, 2 Jan 2023 11:32:01 +0900
> > > > Taka
Hi Corinna,
On Mon, 9 Jan 2023 14:20:56 +0100
Corinna Vinschen wrote:
> On Jan 2 17:21, Takashi Yano via Cygwin wrote:
> > On Mon, 2 Jan 2023 14:38:03 +0900
> > Takashi Yano wrote:
> > > On Mon, 2 Jan 2023 11:32:01 +0900
> > > Takashi Yano wrote:
> > > > On Sat, 31 Dec 2022 13:01:29 -0700
> > > >
On Jan 10 19:01, Takashi Yano via Cygwin wrote:
> On Mon, 9 Jan 2023 18:13:26 +0100
> Corinna Vinschen wrote:
> > If q->sigtls is NULL, the signal is nevertheless waiting for being
> > handled. It's just not directed at a specific thread. Beats me, why
> > this didn't occur in my testing. The pr
On Mon, 9 Jan 2023 18:13:26 +0100
Corinna Vinschen wrote:
> If q->sigtls is NULL, the signal is nevertheless waiting for being
> handled. It's just not directed at a specific thread. Beats me, why
> this didn't occur in my testing. The process signal info should contain
> the process-wide mask o
On Mon, 9 Jan 2023 14:36:44 +0100, Corinna Vinschen wrote:> On Dec 29 21:59,
Brian Inglis via Cygwin wrote:
I got some hangs (deadlock?) between (parallel?) make jobs, top, procps, and
even ls /proc/*/ when trying to cygport all check curl or look at the
process statuses when builds hung un
On Jan 2 11:32, Takashi Yano via Cygwin wrote:
> On Thu, 29 Dec 2022 21:59:45 -0700
> Brian Inglis wrote:
> > I got some hangs (deadlock?) between (parallel?) make jobs, top, procps,
> > and
> > even ls /proc/*/ when trying to cygport all check curl or look at the
&
On Jan 3 08:03, Takashi Yano via Cygwin wrote:
> On Mon, 2 Jan 2023 11:32:01 +0900
> Takashi Yano wrote:
> > On Thu, 29 Dec 2022 21:59:45 -0700
> > Brian Inglis wrote:
> > > I got some hangs (deadlock?) between (parallel?) make jobs, top, procps,
> > > and
&
Hi Brian,
On Dec 29 21:59, Brian Inglis via Cygwin wrote:
> Hi folks,
>
> I got some hangs (deadlock?) between (parallel?) make jobs, top, procps, and
> even ls /proc/*/ when trying to cygport all check curl or look at the
> process statuses when builds hung under Cygwin 3.4.3
On Jan 2 17:21, Takashi Yano via Cygwin wrote:
> On Mon, 2 Jan 2023 14:38:03 +0900
> Takashi Yano wrote:
> > On Mon, 2 Jan 2023 11:32:01 +0900
> > Takashi Yano wrote:
> > > On Sat, 31 Dec 2022 13:01:29 -0700
> > > Brian Inglis wrote:
> > > > was also getting the messages below locally and still on
On Mon, 2 Jan 2023 11:32:01 +0900
Takashi Yano wrote:
> On Thu, 29 Dec 2022 21:59:45 -0700
> Brian Inglis wrote:
> > I got some hangs (deadlock?) between (parallel?) make jobs, top, procps,
> > and
> > even ls /proc/*/ when trying to cygport all check curl or
On Mon, 2 Jan 2023 14:38:03 +0900
Takashi Yano wrote:
> On Mon, 2 Jan 2023 11:32:01 +0900
> Takashi Yano wrote:
> > On Sat, 31 Dec 2022 13:01:29 -0700
> > Brian Inglis wrote:
> > > was also getting the messages below locally and still on GitHub scallywag:
> > >
> > > cygcheck (6936) child_copy:
On Mon, 2 Jan 2023 11:32:01 +0900
Takashi Yano wrote:
> On Sat, 31 Dec 2022 13:01:29 -0700
> Brian Inglis wrote:
> > was also getting the messages below locally and still on GitHub scallywag:
> >
> > cygcheck (6936) child_copy: cygheap read copy failed,
> >
> > ../curl/scallywag/1_x86_64 bui
On Thu, 29 Dec 2022 21:59:45 -0700
Brian Inglis wrote:
> I got some hangs (deadlock?) between (parallel?) make jobs, top, procps, and
> even ls /proc/*/ when trying to cygport all check curl or look at the process
> statuses when builds hung under Cygwin 3.4.3 and 3.5.0-0.69...
&g
On Sat, 31 Dec 2022, Brian Inglis wrote:
> was also getting the messages below locally and still on GitHub scallywag:
>
> cygcheck (6936) child_copy: cygheap read copy failed,
>
> ../curl/scallywag/1_x86_64 build.log:2022-12-26T00:39:35.6163236Z 0
> [main] cygcheck (6936) child_copy:
On 2022-12-29 21:59, Brian Inglis wrote:
I got some hangs (deadlock?) between (parallel?) make jobs, top, procps, and
even ls /proc/*/ when trying to cygport all check curl or look at the process
statuses when builds hung under Cygwin 3.4.3 and 3.5.0-0.69...
Had to revert to a Cygwin 3.4.0
Hi folks,
I got some hangs (deadlock?) between (parallel?) make jobs, top, procps, and
even ls /proc/*/ when trying to cygport all check curl or look at the process
statuses when builds hung under Cygwin 3.4.3 and 3.5.0-0.69...
Had to revert to a Cygwin 3.4.0-344 test build from Dec 16
The following packages have been upgraded in the Cygwin distribution:
* psl 0.21.2
* psl-make-dafsa0.21.2
* libpsl5 0.21.2
* libpsl-devel 0.21.2
* libpsl-doc0.21.2
Public Suffix List library
A public suffix is a domain suffix under
On Mon, Nov 14, 2022 at 10:43:04PM -0800, Ilya Zakharevich wrote:
> If I do
> man man
> in a Windows’ console, I get garbage on screen before I press
> -r
I confirm that this disappeared in the latest(=test) version of cygwin.
However, the following problem remains (although it is probably
Version 4.4-1 of
make
is available in the Cygwin distribution
DESCRIPTION
A GNU tool for controlling the generation of executables and other
non-source files of a program from the program's source files. Make
allows users to build and install packages without any significant
knowledge
The following packages have been upgraded in the Cygwin distribution:
* psl 0.21.1-2
* psl-make-dafsa0.21.1-2
* libpsl5 0.21.1-2
* libpsl-devel 0.21.1-2
* libpsl-doc0.21.1-2
Public Suffix List library
A public suffix is a domain
On Nov 16 18:00, Thomas Wolff wrote:
>
>
> Am 16/11/2022 um 13:52 schrieb Ilya Zakharevich:
> > If I do
> >man man
> > in a Windows’ console, I get garbage on screen before I press
> > -r
> Windows console is what you start with Win+R cmd, right? Works fine for me.
> Why don't you run cy
Am 16/11/2022 um 13:52 schrieb Ilya Zakharevich:
If I do
man man
in a Windows’ console, I get garbage on screen before I press
-r
Windows console is what you start with Win+R cmd, right? Works fine for me.
Why don't you run cygwin programs in a proper cygwin environment to
avoid such
If I do
man man
in a Windows’ console, I get garbage on screen before I press
-r
Contrary to
man man
this cannot be overwritten by setting
set MANPAGER=less -sr
. (However, this may be overwritten by setting
set PAGER=less -sr
)
In my particular setup, it would be enough if the bug w
Am 24/10/2022 um 11:36 schrieb marco atzeri:
On Sun, Oct 23, 2022 at 7:27 PM Ferenc Valenta wrote:
Hi,
Just found a possible issue with Cygwin:
If cygwin is not on the default path, and make is started by specyfing
the path to it (e.g., c:\cygwin64\bin\make), $(MAKE) works in the
top
On Sun, Oct 23, 2022 at 7:27 PM Ferenc Valenta wrote:
>
>
> Hi,
>
> Just found a possible issue with Cygwin:
> If cygwin is not on the default path, and make is started by specyfing
> the path to it (e.g., c:\cygwin64\bin\make), $(MAKE) works in the
> top-level makefile,
Hi,
Just found a possible issue with Cygwin:
If cygwin is not on the default path, and make is started by specyfing
the path to it (e.g., c:\cygwin64\bin\make), $(MAKE) works in the
top-level makefile, but it does not work in make includes.
To reproduce the issue, use these files:
makefile
On Sat, 30 Apr 2022 17:51:03 -0400
Ken Brown wrote:
> On 4/29/2022 5:10 AM, Takashi Yano wrote:
> > On Thu, 28 Apr 2022 17:32:22 +0200
> > I tried to move sigproc_init() call from dll_crt0_0() to
> > fork::child() for 64bit cygwin, however, that causes hang
> > at cygwin startup.
> >
> > Am I miss
On 4/29/2022 5:10 AM, Takashi Yano wrote:
On Thu, 28 Apr 2022 17:32:22 +0200
I tried to move sigproc_init() call from dll_crt0_0() to
fork::child() for 64bit cygwin, however, that causes hang
at cygwin startup.
Am I missing somehting?
I've never looked into the Cygwin startup code, so just ign
On Thu, 28 Apr 2022 17:32:22 +0200
Corinna Vinschen wrote:
> On Apr 29 00:01, Takashi Yano wrote:
> > On Thu, 28 Apr 2022 16:09:24 +0200
> > Corinna Vinschen wrote:
> > > On Apr 28 09:42, Ken Brown wrote:
> > > > On 4/27/2022 10:13 AM, Takashi Yano wrote:
> > > > > On Fri, 1 Apr 2022 17:45:51 +0900
On Apr 29 00:01, Takashi Yano wrote:
> On Thu, 28 Apr 2022 16:09:24 +0200
> Corinna Vinschen wrote:
> > On Apr 28 09:42, Ken Brown wrote:
> > > On 4/27/2022 10:13 AM, Takashi Yano wrote:
> > > > On Fri, 1 Apr 2022 17:45:51 +0900
> > > > Takashi Yano wrote:
> > > > > [...]
> > > > > diff --git a/win
by building OpenJDK
> > > > from source, however, I could not.
> > > >
> > > > Instead, I encountered another issue.
> > > >
> > > > Building OpenJDK sometimes (rarely) failed with error such as:
> > > >
> > > >0
> > > Instead, I encountered another issue.
> > >
> > > Building OpenJDK sometimes (rarely) failed with error such as:
> > >
> > >0 [sig] make 5484 sig_send: error sending signal 11, pid 5484,
> > > pipe handle 0x118, nb 0, packsize
:
0 [sig] make 5484 sig_send: error sending signal 11, pid 5484, pipe
handle 0x118, nb 0, packsize 176, Win32 error 0
124917 [main] make 5484 sig_send: error sending signal -72, pid 5484, pipe
handle 0x118, nb 0, packsize 176, Win32 error 0
common/modules/GensrcModuleInfo.gmk:77: *** open
On Fri, 1 Apr 2022 17:45:51 +0900
Takashi Yano wrote:
> On Mon, 21 Mar 2022 15:28:17 +0100
> Magnus Ihse Bursie wrote:
> > Hi,
> >
> > I'm working for Oracle on the OpenJDK build team. We're using GNU make
> > to build the JDK on all supported platforms
ocess in ProcessHacker, but "ps" and similar
tools in Cygwin still list "javac".
I'm now trying to create a small reproducer that I can share, and I've
had a first small success this night: I could get a very similar hang
with a simple Makefile and a script with Cygw
). So
> there is no javac.exe process in ProcessHacker, but "ps" and similar
> tools in Cygwin still list "javac".
>
> I'm now trying to create a small reproducer that I can share, and I've
> had a first small success this night: I could get a very si
ve
had a first small success this night: I could get a very similar hang
with a simple Makefile and a script with Cygwin 3.3.4. Here is the tree:
make(14479)-+-bash(14484)---bash(14611)
|-bash(14515)---bash(14618)
|-bash(14491)---bash(14500)---bash(14612)
On Thu, 14 Apr 2022 02:17:38 +0300
Alexey Izbyshev wrote:
> On 2022-04-13 19:48, Alexey Izbyshev wrote:
> > On 2022-04-11 13:10, Alexey Izbyshev wrote:
> > What's probably not normal is the behavior of the hanging conhost.exe.
> > I've compared the points where conhost.exe is blocked, and all but o
On 2022-04-13 19:48, Alexey Izbyshev wrote:
On 2022-04-11 13:10, Alexey Izbyshev wrote:
What's probably not normal is the behavior of the hanging conhost.exe.
I've compared the points where conhost.exe is blocked, and all but one
threads in the model case are doing the same things as in the hangi
On 2022-04-13 20:22, Takashi Yano wrote:
On Wed, 13 Apr 2022 19:48:04 +0300
Alexey Izbyshev wrote:
On 2022-04-11 13:10, Alexey Izbyshev wrote:
The good news is that the tests have been running for two days so far
without any cygwin-related issues, so the patched version doesn't seem
to introduce
On Wed, 13 Apr 2022 19:48:04 +0300
Alexey Izbyshev wrote:
> On 2022-04-11 13:10, Alexey Izbyshev wrote:
> > On 2022-04-11 11:35, Takashi Yano wrote:
> >> On Sun, 10 Apr 2022 23:49:29 +0300
> >> A countermeasure version is available at the following location:
> >> https://tyan0.yr32.net/cygwin/x86/t
On 2022-04-11 13:10, Alexey Izbyshev wrote:
On 2022-04-11 11:35, Takashi Yano wrote:
On Sun, 10 Apr 2022 23:49:29 +0300
A countermeasure version is available at the following location:
https://tyan0.yr32.net/cygwin/x86/test/cygwin1-20220411.dll.xz
https://tyan0.yr32.net/cygwin/x86_64/test/cygwin
ee
> rooted at "make", which runs as an ordinary user. Also, wouldn't the hang be
> deterministic if the problem were in the pipe ownership?
Yes it would. I just noticed some of the evidence pointing that way - a
presumably native javac.exe, an anonymous "named pipe"
On 2022-04-11 08:23, Jeremy Drake wrote:
On Sat, 9 Apr 2022, Alexey Izbyshev wrote:
I don't have mintty because "make" is run via an SSH session. I
suppose
I should look into sshd in this case?
Sshd wouldn't happen to be running as a service, would it?
https://cygwin.
peak memory consumption of our tests never exceeds 30% of RAM. Also,
Cygwin is used (almost) exclusively for the test harness (the actual
software under testing is native), and there are no heavyweight
processes in it, mostly just make, bash and some coreutils. So I don't
think we could hit
On 2022-04-11 11:35, Takashi Yano wrote:
On Sun, 10 Apr 2022 23:49:29 +0300
Alexey Izbyshev wrote:
Is it safe to create an *inheritable* handle in another process here?
Could it be that the target process spawns a child at the wrong moment
(e.g. before it even knows about the newly created hand
On Sun, 10 Apr 2022 22:23:06 -0700 (PDT)
Jeremy Drake wrote:
> On Sat, 9 Apr 2022, Alexey Izbyshev wrote:
>
> > I don't have mintty because "make" is run via an SSH session. I suppose
> > I should look into sshd in this case?
>
> Sshd wouldn't
ash.exe
> > is paired with "Unnamed file: \FileSystem\Npfs" in conhost.exe, other
> > than by forcibly closing it. If I close it and conhost.exe dies, it
> > will confirm "the extra handle" theory, but will also prevent further
> > investigation with the hangi
On Sat, 9 Apr 2022, Alexey Izbyshev wrote:
> I don't have mintty because "make" is run via an SSH session. I suppose
> I should look into sshd in this case?
Sshd wouldn't happen to be running as a service, would it?
https://cygwin.com/pipermail/cygwin-patches/2022q2
"the extra handle" theory, but will also prevent further
investigation with the hanging tree. Do you have any advice?
I've found something that looked strange to me by checking handles in
the hanging process tree: the hanging conhost.exe and the hanging
bash.exe belong to dif
On 2022-04-10 10:34, Takashi Yano wrote:
On Sat, 09 Apr 2022 23:26:51 +0300
Thanks for investigating. In the normal case, conhost.exe is terminated
when hWritePipe is closed.
Thanks for confirming.
Possibly, the hWritePipe has incorrect handle value.
I've verified that the handle was corre
On Sat, 09 Apr 2022 23:26:51 +0300
Alexey Izbyshev wrote:
> On 2022-04-09 22:35, Alexey Izbyshev wrote:
> > On 2022-04-09 20:54, Takashi Yano wrote:
> >> Thanks for checking. This seems to be normal. Then, I cannot
> >> understand why the ClosePseudoConsole() call is blocked...
> >>
> >> The docum
On 2022-04-09 22:35, Alexey Izbyshev wrote:
On 2022-04-09 20:54, Takashi Yano wrote:
Thanks for checking. This seems to be normal. Then, I cannot
understand why the ClosePseudoConsole() call is blocked...
The document by Microsoft mentions the blocking conditions of
ClosePseudoConsole():
https:
On 2022-04-09 20:54, Takashi Yano wrote:
Thanks for checking. This seems to be normal. Then, I cannot
understand why the ClosePseudoConsole() call is blocked...
The document by Microsoft mentions the blocking conditions of
ClosePseudoConsole():
https://docs.microsoft.com/en-us/windows/console/cl
On Sat, 09 Apr 2022 20:23:06 +0300
Alexey Izbyshev wrote:
> On 2022-04-09 19:57, Takashi Yano wrote:
> > Thank you very much for the information. Can you check if
> > the thread pty_master_fwd_thread() in root mintty is still
> > alive?
>
> I don't have mintty
On 2022-04-09 19:57, Takashi Yano wrote:
Thank you very much for the information. Can you check if
the thread pty_master_fwd_thread() in root mintty is still
alive?
I don't have mintty because "make" is run via an SSH session. I suppose
I should look into sshd in this case?
essHacker showed that the owner of the pcon mutex is bash.exe with
> (Windows) PID 6276. However, Cygwin ps doesn't list such a process. Its
> parent, however, has a Cygwin PID 37961 and is in the hanging tree:
>
> make(32651)-+-make(32656)-+-bash(37296)---find(38057)
>
1 - 100 of 2000 matches
Mail list logo
