Hi, Takashi,
On 2022-04-27 14:22, Takashi Yano wrote:
Hi Alexey,
On Sat, 16 Apr 2022 16:21:34 +0300
Alexey Izbyshev wrote:
On 2022-04-16 12:39, Takashi Yano wrote:
> I am not sure yet what is essential, but the current code closes
> pseudo console only if there is no other process which is att
Hi Alexey,
On Sat, 16 Apr 2022 16:21:34 +0300
Alexey Izbyshev wrote:
> On 2022-04-16 12:39, Takashi Yano wrote:
> > I am not sure yet what is essential, but the current code closes
> > pseudo console only if there is no other process which is attaching
> > to the pseudo console. I wonder why javac
On 2022-04-16 12:39, Takashi Yano wrote:
I am not sure yet what is essential, but the current code closes
pseudo console only if there is no other process which is attaching
to the pseudo console. I wonder why javac.exe is remaining as
zombie. The parent bash.exe calls ColosePseudoConsole() when
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
On Mon, 11 Apr 2022, Alexey Izbyshev wrote:
> Yes, sshd is running as a service, but I'm not sure that patch is relevant. In
> my case, the problematic pipe that the hanging conhost.exe is waiting on is
> probably created for that specific conhost.exe process within the process tree
> rooted at "m
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.com/pipermail/cygwin-
On 2022-04-08 20:04, Brian Inglis wrote:
On 2022-04-08 02:42, Alexey Izbyshev wrote:
There is also an additional detail that I forgot to mention: in the
stack trace of all leaf processes as displayed by ProcessHacker, it
seems that the executable entry point is not reached yet. The only
non-Wi
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 happen to be running as a service, would it?
>
> htt
On Sun, 10 Apr 2022 23:49:29 +0300
Alexey Izbyshev wrote:
> On 2022-04-10 15:13, Alexey Izbyshev wrote:
> > 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 clo
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/011867.html
--
Problem rep
On 2022-04-10 15:13, Alexey Izbyshev wrote:
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 v
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 because "make" is run via an SSH sess
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? I've checked an ssh
On Sat, 09 Apr 2022 19:07:08 +0300
Alexey Izbyshev wrote:
> On 2022-04-09 14:46, Takashi Yano wrote:
> > On Sat, 09 Apr 2022 14:02:38 +0300
> > Alexey Izbyshev wrote:
> >>
> >> Missed the line in the link above:
> >> https://cygwin.com/git?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/fhandler_tty.cc
On 2022-04-09 14:46, Takashi Yano wrote:
On Sat, 09 Apr 2022 14:02:38 +0300
Alexey Izbyshev wrote:
Missed the line in the link above:
https://cygwin.com/git?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/fhandler_tty.cc;h=7bef6958c106c5e78cc90e014081022fd3a205bc;hb=cygwin-3_3_4-release#l1199
Than
On Sat, 09 Apr 2022 14:02:38 +0300
Alexey Izbyshev wrote:
> On 2022-04-09 14:00, Alexey Izbyshev wrote:
> > On 2022-04-09 13:17, Takashi Yano wrote:
> >
> >> Attaching gdb to the hanging process and dumping stack by 'bt'
> >> command for each thread may diagnose more detail.
> >
> > I decided to
On 2022-04-09 14:00, Alexey Izbyshev wrote:
On 2022-04-09 13:17, Takashi Yano wrote:
Attaching gdb to the hanging process and dumping stack by 'bt'
command for each thread may diagnose more detail.
I decided to simply look at assembly at the point shown in
ProcessHacker stack trace (cygwin1.d
On 2022-04-09 13:17, Takashi Yano wrote:
Attaching gdb to the hanging process and dumping stack by 'bt'
command for each thread may diagnose more detail.
I decided to simply look at assembly at the point shown in ProcessHacker
stack trace (cygwin1.dll!feinitialise+0x5ecab) to avoid disturbing
On Fri, 08 Apr 2022 00:53:31 +0300
Alexey Izbyshev wrote:
> Hi,
>
> I'm using 32-bit Cygwin 3.3.4 on 64-bit Windows 10 21H2. When running
> parallel make (for testing my project), very rarely I get the whole
> process tree hanging at some seemingly random point. An example of such
> a tree:
>
On 2022-04-08 02:42, Alexey Izbyshev wrote:
On 2022-04-08 02:54, Brian Inglis wrote:
I've seen infinite loops with readlink in build scripts under Cygwin.
Seeing that readlink in a process tree makes me suspicious that
something in a shell script is looping because two paths never match
or alw
On 2022-04-08 02:54, Brian Inglis wrote:
I've seen infinite loops with readlink in build scripts under Cygwin.
Seeing that readlink in a process tree makes me suspicious that
something in a shell script is looping because two paths never match
or always match under Cygwin.
Often there is one cons
On 2022-04-07 15:53, Alexey Izbyshev wrote:
I'm using 32-bit Cygwin 3.3.4 on 64-bit Windows 10 21H2. When running
parallel make (for testing my project), very rarely I get the whole
process tree hanging at some seemingly random point. An example of such
a tree:
make-+-make-+-bash---find
Hi,
I'm using 32-bit Cygwin 3.3.4 on 64-bit Windows 10 21H2. When running
parallel make (for testing my project), very rarely I get the whole
process tree hanging at some seemingly random point. An example of such
a tree:
make-+-make-+-bash---find
| |-bash---find
| |-bash
32 matches
Mail list logo
