Re: [PATCH] Cygwin: pipe: Give up to use query_hdl for non-cygwin apps.

[Takashi Yano]

On Mon, 4 Mar 2024 18:38:07 +0100
Corinna Vinschen wrote:
> On Mar  4 16:45, ASSI wrote:
> > Corinna Vinschen writes:
> > > Right you are.  We always said that independent Cygwin installations
> > > are supposed to *stay* independent.
> > >
> > > Keep in mind that they don't share the same shared objects in the native
> > > NT namespace and they don't know of each other.  It's not only the
> > > process table but also in-use FIFO stuff, pty info, etc.
> > 
> > What I was getting at is that a process not showing up in the process
> > list in one Cygwin installation doesn't automatically mean it's a native
> > Windows process, it could be a process started by an independent Cygwin
> > installation.  So this way of checking for "native" Windows processes
> > may or may not do what was originally intended.
> 
> But that was my point. A "foreign" Cygwin process from another
> installation is not a Cygwin process.  Lots of interoperability
> just won't work, so it's basically a native process.

Actually, I think query_hdl can be retrieved from the process
from another installation of cygwin using NtQueryInformationProcess()
with ProcessHandleInformation. However, I cannot imagne the case
that the pipe is made by one cygwin installation but the reader
process is from another installation of cygwin.

BTW, what about v2 patch itself?

-- 
Takashi Yano 

Re: Regression: Cygwin 3.5.1 freezes when launching several mingw processes in parallel

[Dimitry Andric via Cygwin]

It's already been backported here: 
https://cygwin.com/cgit/newlib-cygwin/commit/?h=cygwin-3_5-branch=fc5e9525453fea7c27b0e13635ae54abaa0db69d

So I would guess a version 3.5.2 is very likely to appear.

-Dimitry

> On 4 Mar 2024, at 20:54, Cedric Blancher via Cygwin  wrote:
> 
> Same here building gcc with the msnfs41client NFSv4.1 filesystem
> driver (https://sourceforge.net/p/ms-nfs41-client/mailman/message/58741244/),
> make -j8 and make -j128 builds now succeed again.
> 
> Is a Cygwin 3.5.x backport required?
> 
> Ced
> 
> On Mon, 4 Mar 2024 at 20:38, Dimitry Andric via Cygwin
>  wrote:
>> 
>> Same here, did a bunch of make -j8 builds, and with 3.6.0-0.71.gb160b690b6ac 
>> they now complete without any hangs.
>> 
>> Thanks for the quick fix!
>> 
>> -Dimitry
>> 
>>> On 4 Mar 2024, at 16:58, Kate Deplaix via Cygwin  wrote:
>>> 
>>> After testing that version without interruption for the past 3 hours on 
>>> test cases that would've failed before, I can happily say it looks like 
>>> it's fixed!
>>> 
>>> Thank you so much!!
>>> 
>>> From: Cygwin  on behalf 
>>> of Takashi Yano via Cygwin 
>>> Sent: 04 March 2024 12:06
>>> To: cygwin@cygwin.com 
>>> Subject: Re: Regression: Cygwin 3.5.1 freezes when launching several mingw 
>>> processes in parallel
>>> 
>>> On Mon, 4 Mar 2024 20:00:13 +0900
>>> Takashi Yano via Cygwin wrote:
 On Sun, 3 Mar 2024 13:07:11 +0900
 Takashi Yano wrote:
> On Sat, 2 Mar 2024 11:49:36 +
> Kate Deplaix wrote:
>> I'm running cygwin on baremetal on an Intel i5-750 (4 cores), with 7GB 
>> of RAM and with an up-to-date Windows 10.
> 
> Thanks for the information. I could reproduce the problem with
> Core i5 M 540 + 8GB RAM machine.
> 
> Let consider how to debug.
 
 I found the cause. I'll push the patch shortly.
 Thanks!
>>> 
>>> Please try:
>>> cygwin 3.6.0-0.71.gb160b690b6ac (TEST)
>>> 
>>> --
>>> Takashi Yano 
>>> 
>>> --
>>> Problem reports:  https://cygwin.com/problems.html
>>> FAQ:  https://cygwin.com/faq/
>>> Documentation:https://cygwin.com/docs.html
>>> Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
>>> 
>>> --
>>> Problem reports:  https://cygwin.com/problems.html
>>> FAQ:  https://cygwin.com/faq/
>>> Documentation:https://cygwin.com/docs.html
>>> Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
>> 
>> 
>> --
>> Problem reports:  https://cygwin.com/problems.html
>> FAQ:  https://cygwin.com/faq/
>> Documentation:https://cygwin.com/docs.html
>> Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
> 
> 
> 
> -- 
> Cedric Blancher 
> [https://plus.google.com/u/0/+CedricBlancher/]
> Institute Pasteur
> 
> -- 
> Problem reports:  https://cygwin.com/problems.html
> FAQ:  https://cygwin.com/faq/
> Documentation:https://cygwin.com/docs.html
> Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: [ATTN. MAINTAINER] units

[Brian Inglis via Cygwin-apps]

On 2024-03-04 12:54, ASSI via Cygwin-apps wrote:

The postinstall script for units downloads currency exchange rates and
hangs up for a long time if it can't access the server (if it ever
finishes, I've killed the process on all machines where I've seen this).
Can this part please either be removed entirely or moved into a
sub-package that doen't get installed by default?


Hi Achim,

Sorry I thought I had dropped that in favour of mentioning it in release notes.

I know some sources have changed so may again be causing an issue.
I will review and release -2 when I get a chance so I do not forget in future.

Can anyone recommend robust tests for network and also site access that I could 
add?


--
Take care. Thanks, Brian Inglis  Calgary, Alberta, Canada

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry

Re: mingw cross tests missing DLLs - CROSS_BINDIR not in PATH

[Brian Inglis via Cygwin-apps]

On 2024-03-04 13:00, Jon Turney wrote:

On 03/03/2024 22:29, Brian Inglis via Cygwin-apps wrote:

On 2024-03-03 14:39, Jon Turney via Cygwin-apps wrote:

On 03/03/2024 16:48, Brian Inglis via Cygwin-apps wrote:
I am finding mingw package cross tests fail with missing DLLs - CROSS_BINDIR 
is not in the PATH.


I now have to define src_test to run cygtest adding CROSS_BINDIR in the PATH.

Is this likely to be upstream (e.g. gnulib) changes or cygport changes?


This is a shortcoming of cygport, in that you cannot just write "do the 
standard src_(compile|install|test), but do this extra thing first (like 
modifying PATH as you need in this case).


(One approach to this I've though about would be to have a hook function (or 
set of functions) which are called before each phase of operation, to allow 
this)


These test failures have been only in the latest upstream releases.
Previously no PATH fiddling was required.
For mingw64-x86_64-nghttp2 that was 2024-01-21.

Why I asked if anyone noticed any cross build changes as for example in 
autotools, gnulib, or cygport?


I assumed that you were talking about "PATH needs to be set so that dependencies 
of the built DLL can be loaded"


But, now I look, mingw64-x86_64-nghttp2 doesn't have any dependencies.

So, I'm not so sure. Maybe you just mean that the test harness can't locate the 
just built DLL? That could well be an upstream change.


Maybe you could show the actual error?


Sorry I was not clearer.
In previous release build checks there were no issues.
In the latest release the test programs have a dependency on winpthreads and 
failed with popup dialogues:


main.exe - System Error ...
ALSO
failmalloc.exe - System Error
X
The code execution cannot proceed because
libwinpthread-1.dll was not found.
Reinstalling the program may fix this problem.

$ cygcheck -f /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libwinpthread-1.dll
mingw64-x86_64-winpthreads-11.0.1-1

Similar result as:

$ cygcheck mingw64-x86_64-nghttp2-1.60.0-1.noarch/build/tests/{main,failmalloc}
cygcheck: track_down: could not find libwinpthread-1.dll

C:/.../usr/src/nghttp2/mingw64-x86_64-nghttp2/mingw64-x86_64-nghttp2-1.60.0-1.noarch/build/tests/main.exe
  C:/WINDOWS/system32/KERNEL32.dll
C:/WINDOWS/system32/ntdll.dll
C:/WINDOWS/system32/KERNELBASE.dll
  C:/WINDOWS/system32/msvcrt.dll

cygcheck: track_down: could not find libwinpthread-1.dll

C:/.../usr/src/nghttp2/mingw64-x86_64-nghttp2/mingw64-x86_64-nghttp2-1.60.0-1.noarch/build/tests/failmalloc.exe
  C:/WINDOWS/system32/KERNEL32.dll
C:/WINDOWS/system32/ntdll.dll
C:/WINDOWS/system32/KERNELBASE.dll
  C:/WINDOWS/system32/msvcrt.dll
$ PATH="/usr/x86_64-w64-mingw32/sys-root/mingw/bin/:$PATH"\
cygcheck mingw64-x86_64-nghttp2-1.60.0-1.noarch/build/tests/{main,failmalloc}
C:/.../usr/src/nghttp2/mingw64-x86_64-nghttp2/mingw64-x86_64-nghttp2-1.60.0-1.noarch/build/tests/main.exe
  C:/WINDOWS/system32/KERNEL32.dll
C:/WINDOWS/system32/ntdll.dll
C:/WINDOWS/system32/KERNELBASE.dll
  C:/WINDOWS/system32/msvcrt.dll
  C:/.../usr/x86_64-w64-mingw32/sys-root/mingw/bin/libwinpthread-1.dll

C:/.../usr/src/nghttp2/mingw64-x86_64-nghttp2/mingw64-x86_64-nghttp2-1.60.0-1.noarch/build/tests/failmalloc.exe
  C:/WINDOWS/system32/KERNEL32.dll
C:/WINDOWS/system32/ntdll.dll
C:/WINDOWS/system32/KERNELBASE.dll
  C:/WINDOWS/system32/msvcrt.dll
  C:/.../usr/x86_64-w64-mingw32/sys-root/mingw/bin/libwinpthread-1.dll

--
Take care. Thanks, Brian Inglis  Calgary, Alberta, Canada

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry

Re: mingw cross tests missing DLLs - CROSS_BINDIR not in PATH

[Jon Turney via Cygwin-apps]

On 03/03/2024 22:29, Brian Inglis via Cygwin-apps wrote:

On 2024-03-03 14:39, Jon Turney via Cygwin-apps wrote:

On 03/03/2024 16:48, Brian Inglis via Cygwin-apps wrote:
I am finding mingw package cross tests fail with missing DLLs - 
CROSS_BINDIR is not in the PATH.


I now have to define src_test to run cygtest adding CROSS_BINDIR in 
the PATH.


Is this likely to be upstream (e.g. gnulib) changes or cygport changes?


This is a shortcoming of cygport, in that you cannot just write "do 
the standard src_(compile|install|test), but do this extra thing first 
(like modifying PATH as you need in this case).


(One approach to this I've though about would be to have a hook 
function (or set of functions) which are called before each phase of 
operation, to allow this)


These test failures have been only in the latest upstream releases.
Previously no PATH fiddling was required.
For mingw64-x86_64-nghttp2 that was 2024-01-21.

Why I asked if anyone noticed any cross build changes as for example in 
autotools, gnulib, or cygport?


I assumed that you were talking about "PATH needs to be set so that 
dependencies of the built DLL can be loaded"


But, now I look, mingw64-x86_64-nghttp2 doesn't have any dependencies.

So, I'm not so sure. Maybe you just mean that the test harness can't 
locate the just built DLL? That could well be an upstream change.


Maybe you could show the actual error?

Re: Regression: Cygwin 3.5.1 freezes when launching several mingw processes in parallel

[Cedric Blancher via Cygwin]

Same here building gcc with the msnfs41client NFSv4.1 filesystem
driver (https://sourceforge.net/p/ms-nfs41-client/mailman/message/58741244/),
make -j8 and make -j128 builds now succeed again.

Is a Cygwin 3.5.x backport required?

Ced

On Mon, 4 Mar 2024 at 20:38, Dimitry Andric via Cygwin
 wrote:
>
> Same here, did a bunch of make -j8 builds, and with 3.6.0-0.71.gb160b690b6ac 
> they now complete without any hangs.
>
> Thanks for the quick fix!
>
> -Dimitry
>
> > On 4 Mar 2024, at 16:58, Kate Deplaix via Cygwin  wrote:
> >
> > After testing that version without interruption for the past 3 hours on 
> > test cases that would've failed before, I can happily say it looks like 
> > it's fixed!
> >
> > Thank you so much!!
> > 
> > From: Cygwin  on behalf 
> > of Takashi Yano via Cygwin 
> > Sent: 04 March 2024 12:06
> > To: cygwin@cygwin.com 
> > Subject: Re: Regression: Cygwin 3.5.1 freezes when launching several mingw 
> > processes in parallel
> >
> > On Mon, 4 Mar 2024 20:00:13 +0900
> > Takashi Yano via Cygwin wrote:
> >> On Sun, 3 Mar 2024 13:07:11 +0900
> >> Takashi Yano wrote:
> >>> On Sat, 2 Mar 2024 11:49:36 +
> >>> Kate Deplaix wrote:
>  I'm running cygwin on baremetal on an Intel i5-750 (4 cores), with 7GB 
>  of RAM and with an up-to-date Windows 10.
> >>>
> >>> Thanks for the information. I could reproduce the problem with
> >>> Core i5 M 540 + 8GB RAM machine.
> >>>
> >>> Let consider how to debug.
> >>
> >> I found the cause. I'll push the patch shortly.
> >> Thanks!
> >
> > Please try:
> > cygwin 3.6.0-0.71.gb160b690b6ac (TEST)
> >
> > --
> > Takashi Yano 
> >
> > --
> > Problem reports:  https://cygwin.com/problems.html
> > FAQ:  https://cygwin.com/faq/
> > Documentation:https://cygwin.com/docs.html
> > Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
> >
> > --
> > Problem reports:  https://cygwin.com/problems.html
> > FAQ:  https://cygwin.com/faq/
> > Documentation:https://cygwin.com/docs.html
> > Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
>
>
> --
> Problem reports:  https://cygwin.com/problems.html
> FAQ:  https://cygwin.com/faq/
> Documentation:https://cygwin.com/docs.html
> Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple



-- 
Cedric Blancher 
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

[ATTN. MAINTAINER] units

[ASSI via Cygwin-apps]

The postinstall script for units downloads currency exchange rates and
hangs up for a long time if it can't access the server (if it ever
finishes, I've killed the process on all machines where I've seen this).
Can this part please either be removed entirely or moved into a
sub-package that doen't get installed by default?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

gdb 14.2-1 (TEST)

[Jon Turney via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* gdb-14.2-1
* gdb-debuginfo-14.2-1
* gdb-multiarch-14.2-1

The GNU debugger, allows you to debug programs written in C, C++,
and other languages, by executing them in a controlled fashion
and printing their data.

This is an update to the latest upstream version:

https://sourceware.org/pipermail/gdb-announce/2024/000138.html

See the /usr/share/doc/gdb/NEWS file for a list of user-visible changes.

In addition, it contains the following patches carried forward from the 
previous Cygwin package:

* Teach the demangler to deal with '@'-decorated __stdcall functions
* (experimental) Teach gdb how to unwind frames for the Cygwin signal delivery 
wrapper functions _sigbe and sigdelayed
* Fix a memory leak which would occur in the case when the result of realpath() 
is greater than or equal to SO_NAME_MAX_PATH_SIZE (Corinna Vinschen)
* Simplify and improve handling of inferior context after a Cygwin signal
* Use cygwin pgid if inferior is a cygwin process (Takashi Yano)


-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

The easiest way to unsubscribe is to visit 
, and click 'Unsubscribe'.

If you need more information on unsubscribing, start reading here: 
.

Re: Regression: Cygwin 3.5.1 freezes when launching several mingw processes in parallel

[Dimitry Andric via Cygwin]

Same here, did a bunch of make -j8 builds, and with 3.6.0-0.71.gb160b690b6ac 
they now complete without any hangs.

Thanks for the quick fix!

-Dimitry

> On 4 Mar 2024, at 16:58, Kate Deplaix via Cygwin  wrote:
> 
> After testing that version without interruption for the past 3 hours on test 
> cases that would've failed before, I can happily say it looks like it's fixed!
> 
> Thank you so much!!
> 
> From: Cygwin  on behalf of 
> Takashi Yano via Cygwin 
> Sent: 04 March 2024 12:06
> To: cygwin@cygwin.com 
> Subject: Re: Regression: Cygwin 3.5.1 freezes when launching several mingw 
> processes in parallel
> 
> On Mon, 4 Mar 2024 20:00:13 +0900
> Takashi Yano via Cygwin wrote:
>> On Sun, 3 Mar 2024 13:07:11 +0900
>> Takashi Yano wrote:
>>> On Sat, 2 Mar 2024 11:49:36 +
>>> Kate Deplaix wrote:
 I'm running cygwin on baremetal on an Intel i5-750 (4 cores), with 7GB of 
 RAM and with an up-to-date Windows 10.
>>> 
>>> Thanks for the information. I could reproduce the problem with
>>> Core i5 M 540 + 8GB RAM machine.
>>> 
>>> Let consider how to debug.
>> 
>> I found the cause. I'll push the patch shortly.
>> Thanks!
> 
> Please try:
> cygwin 3.6.0-0.71.gb160b690b6ac (TEST)
> 
> --
> Takashi Yano 
> 
> --
> Problem reports:  https://cygwin.com/problems.html
> FAQ:  https://cygwin.com/faq/
> Documentation:https://cygwin.com/docs.html
> Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
> 
> -- 
> Problem reports:  https://cygwin.com/problems.html
> FAQ:  https://cygwin.com/faq/
> Documentation:https://cygwin.com/docs.html
> Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: [PATCH] Cygwin: pipe: Give up to use query_hdl for non-cygwin apps.

[Corinna Vinschen]

On Mar  4 16:45, ASSI wrote:
> Corinna Vinschen writes:
> > Right you are.  We always said that independent Cygwin installations
> > are supposed to *stay* independent.
> >
> > Keep in mind that they don't share the same shared objects in the native
> > NT namespace and they don't know of each other.  It's not only the
> > process table but also in-use FIFO stuff, pty info, etc.
> 
> What I was getting at is that a process not showing up in the process
> list in one Cygwin installation doesn't automatically mean it's a native
> Windows process, it could be a process started by an independent Cygwin
> installation.  So this way of checking for "native" Windows processes
> may or may not do what was originally intended.

But that was my point. A "foreign" Cygwin process from another
installation is not a Cygwin process.  Lots of interoperability
just won't work, so it's basically a native process.


Corinna

Re: Regression: Cygwin 3.5.1 freezes when launching several mingw processes in parallel

[Kate Deplaix via Cygwin]

After testing that version without interruption for the past 3 hours on test 
cases that would've failed before, I can happily say it looks like it's fixed!

Thank you so much!!

From: Cygwin  on behalf of 
Takashi Yano via Cygwin 
Sent: 04 March 2024 12:06
To: cygwin@cygwin.com 
Subject: Re: Regression: Cygwin 3.5.1 freezes when launching several mingw 
processes in parallel

On Mon, 4 Mar 2024 20:00:13 +0900
Takashi Yano via Cygwin wrote:
> On Sun, 3 Mar 2024 13:07:11 +0900
> Takashi Yano wrote:
> > On Sat, 2 Mar 2024 11:49:36 +
> > Kate Deplaix wrote:
> > > I'm running cygwin on baremetal on an Intel i5-750 (4 cores), with 7GB of 
> > > RAM and with an up-to-date Windows 10.
> >
> > Thanks for the information. I could reproduce the problem with
> > Core i5 M 540 + 8GB RAM machine.
> >
> > Let consider how to debug.
>
> I found the cause. I'll push the patch shortly.
> Thanks!

Please try:
cygwin 3.6.0-0.71.gb160b690b6ac (TEST)

--
Takashi Yano 

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: [PATCH] Cygwin: pipe: Give up to use query_hdl for non-cygwin apps.

[ASSI]

Corinna Vinschen writes:
> Right you are.  We always said that independent Cygwin installations
> are supposed to *stay* independent.
>
> Keep in mind that they don't share the same shared objects in the native
> NT namespace and they don't know of each other.  It's not only the
> process table but also in-use FIFO stuff, pty info, etc.

What I was getting at is that a process not showing up in the process
list in one Cygwin installation doesn't automatically mean it's a native
Windows process, it could be a process started by an independent Cygwin
installation.  So this way of checking for "native" Windows processes
may or may not do what was originally intended.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Updated: openjpeg2-2.5.2-1

[Lemures Lemniscati via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* libopenjp2-devel-2.5.2-1.tar.xz
* libopenjp2-doc-2.5.2-1.tar.xz
* libopenjp2_7-2.5.2-1.tar.xz
* openjpeg2-2.5.2-1.tar.xz

* openjpeg2-2.5.2-1-src.tar.xz
* openjpeg2-debuginfo-2.5.2-1.tar.xz

This is an update to the latest upstream.

--
The OpenJPEG library is an open-source JPEG 2000 codec written in C
language. It has been developed in order to promote the use of JPEG
2000, the new still-image compression standard from the Joint
Photographic Experts Group (JPEG).


HomePage: http://www.openjpeg.org/
News: https://github.com/uclouvain/openjpeg/releases/
Source: 
https://github.com/uclouvain/openjpeg/archive/v2.5.2/openjpeg-v2.5.2.tar.gz
License: BSD-2-Clause https://github.com/uclouvain/openjpeg/blob/master/LICENSE

Cygwin Package Summary:
  https://www.cygwin.com/packages/summary/openjpeg2-src.html
Cygport Source:
  https://cygwin.com/git/?p=git/cygwin-packages/openjpeg2.git

--
Lemures Lemniscati

-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

The easiest way to unsubscribe is to visit 
, and click 'Unsubscribe'.

If you need more information on unsubscribing, start reading here: 
.

Re: Regression: Cygwin 3.5.1 freezes when launching several mingw processes in parallel

[Dimitry Andric via Cygwin]

I think I've been experiencing something similar with 3.5.1, where date.exe 
randomly hangs with a full core pegged. Loading it in gdb shows:

Thread 1 received signal SIGTRAP, Trace/breakpoint trap.
0x7ffe23b0b503 in KERNELBASE!DebugBreak () from 
/cygdrive/c/Windows/System32/KERNELBASE.dll
(gdb) bt
#0  0x7ffe23b0b503 in KERNELBASE!DebugBreak () from 
/cygdrive/c/Windows/System32/KERNELBASE.dll
#1  0x7ffe19cf6367 in break_here () at 
/usr/src/debug/cygwin-3.5.1-1/winsup/cygwin/dcrt0.cc:472
#2  0x7ffe19d10339 in try_to_debug () at 
/usr/src/debug/cygwin-3.5.1-1/winsup/cygwin/exceptions.cc:597
#3  exception::handle (e=0x7c7b0, frame=, in=0x7c2c0, 
dispatch=)
at /usr/src/debug/cygwin-3.5.1-1/winsup/cygwin/exceptions.cc:810
#4  0x7ffe261123af in ntdll!.chkstk () from 
/cygdrive/c/Windows/SYSTEM32/ntdll.dll
#5  0x7ffe260c14b4 in ntdll!RtlRaiseException () from 
/cygdrive/c/Windows/SYSTEM32/ntdll.dll
#6  0x7ffe26110ebe in ntdll!KiUserExceptionDispatcher () from 
/cygdrive/c/Windows/SYSTEM32/ntdll.dll
#7  0x7ffe19da92d7 in fhandler_console::set_output_mode (m=(unknown: 
0x2610d444), t=0x1, p=0x7b9e8)
at /usr/src/debug/cygwin-3.5.1-1/winsup/cygwin/fhandler/console.cc:843
#8  0x7ffe19d095ca in dtable::init_std_file_from_handle (this=, fd=, handle=0x)
at /usr/src/debug/cygwin-3.5.1-1/winsup/cygwin/dtable.cc:425
#9  0x7ffe19d099c2 in dtable::stdio_init (this=0x84870) at 
/usr/src/debug/cygwin-3.5.1-1/winsup/cygwin/dtable.cc:186
#10 0x7ffe19cf7187 in dll_crt0_1 () at 
/usr/src/debug/cygwin-3.5.1-1/winsup/cygwin/dcrt0.cc:925
#11 0x7ffe19cf5e08 in _cygtls::call2 (this=0x7ce00, func=0x7ffe19cf6fb8 
, arg=0x0, buf=buf@entry=0x7cdf0)
at /usr/src/debug/cygwin-3.5.1-1/winsup/cygwin/cygtls.cc:41
#12 0x7ffe19cf5e86 in _cygtls::call (func=, arg=) at /usr/src/debug/cygwin-3.5.1-1/winsup/cygwin/cygtls.cc:28
#13 0x in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

I will check out 3.6.0-0.71.gb160b690b6ac to see if it fixes this hang.

-Dimitry

> On 4 Mar 2024, at 13:06, Takashi Yano via Cygwin  wrote:
> 
> On Mon, 4 Mar 2024 20:00:13 +0900
> Takashi Yano via Cygwin wrote:
>> On Sun, 3 Mar 2024 13:07:11 +0900
>> Takashi Yano wrote:
>>> On Sat, 2 Mar 2024 11:49:36 +
>>> Kate Deplaix wrote:
 I'm running cygwin on baremetal on an Intel i5-750 (4 cores), with 7GB of 
 RAM and with an up-to-date Windows 10.
>>> 
>>> Thanks for the information. I could reproduce the problem with
>>> Core i5 M 540 + 8GB RAM machine.
>>> 
>>> Let consider how to debug.
>> 
>> I found the cause. I'll push the patch shortly.
>> Thanks!
> 
> Please try:
> cygwin 3.6.0-0.71.gb160b690b6ac (TEST)
> 
> -- 
> Takashi Yano 
> 
> -- 
> Problem reports:  https://cygwin.com/problems.html
> FAQ:  https://cygwin.com/faq/
> Documentation:https://cygwin.com/docs.html
> Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Regression: Cygwin 3.5.1 freezes when launching several mingw processes in parallel

[Takashi Yano via Cygwin]

On Mon, 4 Mar 2024 20:00:13 +0900
Takashi Yano via Cygwin wrote:
> On Sun, 3 Mar 2024 13:07:11 +0900
> Takashi Yano wrote:
> > On Sat, 2 Mar 2024 11:49:36 +
> > Kate Deplaix wrote:
> > > I'm running cygwin on baremetal on an Intel i5-750 (4 cores), with 7GB of 
> > > RAM and with an up-to-date Windows 10.
> > 
> > Thanks for the information. I could reproduce the problem with
> > Core i5 M 540 + 8GB RAM machine.
> > 
> > Let consider how to debug.
> 
> I found the cause. I'll push the patch shortly.
> Thanks!

Please try:
cygwin 3.6.0-0.71.gb160b690b6ac (TEST)

-- 
Takashi Yano 

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Regression: Cygwin 3.5.1 freezes when launching several mingw processes in parallel

[Takashi Yano via Cygwin]

On Sun, 3 Mar 2024 13:07:11 +0900
Takashi Yano wrote:
> On Sat, 2 Mar 2024 11:49:36 +
> Kate Deplaix wrote:
> > I'm running cygwin on baremetal on an Intel i5-750 (4 cores), with 7GB of 
> > RAM and with an up-to-date Windows 10.
> 
> Thanks for the information. I could reproduce the problem with
> Core i5 M 540 + 8GB RAM machine.
> 
> Let consider how to debug.

I found the cause. I'll push the patch shortly.
Thanks!

-- 
Takashi Yano 

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

[PATCH] Cygwin: console: Fix a race issue between close() and open().

[Takashi Yano]

The open() call for console sometimes fails if the console owner
process is closing the console by close() at the same time. This
is due to mismatch state of con.owner variable and attaching state
to the console. With this patch, checking con.owner and attaching
to con.owner sequence in open(), and resetting con.owner and freeing
console sequence in close() are guarded by output_mutex to avoid
such a race issue.
Addresses: https://cygwin.com/pipermail/cygwin/2024-March/255575.html

Fixes: 3721a756b0d8 ("Cygwin: console: Make the console accessible from other 
terminals.")
Reported-by: Kate Deplaix 
Signed-off-by: Takashi Yano 
---
 winsup/cygwin/fhandler/console.cc | 58 ++-
 winsup/cygwin/release/3.5.2   |  4 +++
 2 files changed, 38 insertions(+), 24 deletions(-)

diff --git a/winsup/cygwin/fhandler/console.cc 
b/winsup/cygwin/fhandler/console.cc
index 67ea95466..1c0d5c815 100644
--- a/winsup/cygwin/fhandler/console.cc
+++ b/winsup/cygwin/fhandler/console.cc
@@ -687,14 +687,6 @@ fhandler_console::set_unit ()
 {
   devset = (fh_devices) shared_console_info[unit]->tty_min_state.getntty 
();
   _tc = &(shared_console_info[unit]->tty_min_state);
-  if (!created)
-   {
- while (con.owner > MAX_PID)
-   Sleep (1);
- pinfo p (con.owner);
- if (!p)
-   con.owner = myself->pid;
-   }
 }
 
   dev ().parse (devset);
@@ -1744,11 +1736,23 @@ fhandler_console::open (int flags, mode_t)
   set_handle (NULL);
   set_output_handle (NULL);
 
+  setup_io_mutex ();
+  acquire_output_mutex (mutex_timeout);
+
+  do
+{
+  pinfo p (con.owner);
+  if (!p)
+   con.owner = myself->pid;
+}
+  while (false);
+
   /* Open the input handle as handle_ */
   bool err = false;
   DWORD resume_pid = attach_console (con.owner, );
   if (err)
 {
+  release_output_mutex ();
   set_errno (EACCES);
   return 0;
 }
@@ -1759,6 +1763,7 @@ fhandler_console::open (int flags, mode_t)
 
   if (h == INVALID_HANDLE_VALUE)
 {
+  release_output_mutex ();
   __seterrno ();
   return 0;
 }
@@ -1768,6 +1773,7 @@ fhandler_console::open (int flags, mode_t)
   resume_pid = attach_console (con.owner, );
   if (err)
 {
+  release_output_mutex ();
   set_errno (EACCES);
   return 0;
 }
@@ -1778,14 +1784,16 @@ fhandler_console::open (int flags, mode_t)
 
   if (h == INVALID_HANDLE_VALUE)
 {
+  release_output_mutex ();
   __seterrno ();
   return 0;
 }
   set_output_handle (h);
   handle_set.output_handle = h;
+  release_output_mutex ();
+
   wpbuf.init ();
 
-  setup_io_mutex ();
   handle_set.input_mutex = input_mutex;
   handle_set.output_mutex = output_mutex;
 
@@ -1895,25 +1903,20 @@ fhandler_console::close ()
}
 }
 
-  release_output_mutex ();
-
-  if (shared_console_info[unit] && con.owner == myself->pid
-  && master_thread_started)
+  if (shared_console_info[unit] && con.owner == myself->pid)
 {
-  char name[MAX_PATH];
-  shared_name (name, CONS_THREAD_SYNC, get_minor ());
-  thread_sync_event = OpenEvent (MAXIMUM_ALLOWED, FALSE, name);
-  con.owner = MAX_PID + 1;
-  WaitForSingleObject (thread_sync_event, INFINITE);
-  CloseHandle (thread_sync_event);
+  if (master_thread_started)
+   {
+ char name[MAX_PATH];
+ shared_name (name, CONS_THREAD_SYNC, get_minor ());
+ thread_sync_event = OpenEvent (MAXIMUM_ALLOWED, FALSE, name);
+ con.owner = MAX_PID + 1;
+ WaitForSingleObject (thread_sync_event, INFINITE);
+ CloseHandle (thread_sync_event);
+   }
   con.owner = 0;
 }
 
-  CloseHandle (input_mutex);
-  input_mutex = NULL;
-  CloseHandle (output_mutex);
-  output_mutex = NULL;
-
   CloseHandle (get_handle ());
   CloseHandle (get_output_handle ());
 
@@ -1926,6 +1929,13 @@ fhandler_console::close ()
  || get_device () == (dev_t) myself->ctty))
 free_console ();
 
+  release_output_mutex ();
+
+  CloseHandle (input_mutex);
+  input_mutex = NULL;
+  CloseHandle (output_mutex);
+  output_mutex = NULL;
+
   if (shared_console_info[unit] && myself->ctty != tc ()->ntty)
 {
   UnmapViewOfFile ((void *) shared_console_info[unit]);
diff --git a/winsup/cygwin/release/3.5.2 b/winsup/cygwin/release/3.5.2
index 7d8df9489..fd3c768de 100644
--- a/winsup/cygwin/release/3.5.2
+++ b/winsup/cygwin/release/3.5.2
@@ -5,3 +5,7 @@ Fixes:
   is already unmapped due to race condition. To avoid this issue,
   shared console memory will be kept mapped if it belongs to CTTY.
   Addresses:  https://cygwin.com/pipermail/cygwin/2024-February/255561.html
+
+- Fix a race issue between console open() and close() which is caused
+  by state mismatch between con.owner and console attaching state.
+  Addresses: https://cygwin.com/pipermail/cygwin/2024-March/255575.html
-- 
2.43.0

Re: [PATCH] Cygwin: pipe: Give up to use query_hdl for non-cygwin apps.

[Corinna Vinschen]

On Mar  3 20:36, Takashi Yano wrote:
> On Sun, 03 Mar 2024 11:39:40 +0100
> ASSI wrote:
> > Takashi Yano writes:
> > >> After noticing that we enumerate all the processes (which is an expensive
> > >> operation) just to skip all of the non-Cygwin ones anyway, I wonder if it
> > >> wouldn't be smarter to go through the internal list of cygpids and take 
> > >> it
> > >> from there, skipping the `SystemProcessInformation` calls altogether.
> > >
> > > Yeah, that makes sens. I'll submit v2 patch.
> > 
> > Keep in mind that there may be different independent Cygwin
> > installations running on the same nachine.
> 
> That's possible. But how can we know that is a process in another
> installaion of cygwin?
> 
> If it is difficult, I think it is not so nonsense to treat it as
> same as non-cygwin process.

Right you are.  We always said that independent Cygwin installations
are supposed to *stay* independent.

Keep in mind that they don't share the same shared objects in the native
NT namespace and they don't know of each other.  It's not only the
process table but also in-use FIFO stuff, pty info, etc.


Corinna

Re: UNIX nobody/nogroup mapping to which Windows SID/account?

[Corinna Vinschen via Cygwin]

On Mar  3 14:45, Martin Wege via Cygwin wrote:
> Hello,
> 
> How can we map UNIX "nobody"/"nogroup" to Win32 SIDs/accounts? Cygwin
> has entries for "nobody" in /etc/passwd and "nogroup" in /etc/group,
> but these accounts have SIDs returned by /usr/bin/getent passwd and
> /usr/bin/getent group which LookupAccountSidA() does not recognise.
> 
> So what is the correct Win32 solution?

I urge you to read the entire thread starting at

https://sourceware.org/legacy-ml/cygwin/2016-06/msg00347.html

There's a *LOT* of information in there in terms of discussing and
creating the nobody/nogroup mapping.

Bottom line is, there's no nobody account equivalent on Windows and no
resolvable SID/Name pair.  Thus, we decided to use the SID S-1-0-65534
mapped to uid/gid 65534 for this purpose.  This doesn't matter to native
Windows, it's just some foreign SID.  But it's resolvable inside Cygwin:

  $ getent passwd S-1-0-65534
  no+body:*:65534:65534:U-no\body,S-1-0-65534:/:/sbin/nologin
  $  getent group S-1-0-65534
  no+body:S-1-0-65534:65534:


Corinna

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Convert a file descriptor from Cygwin openat() to Win32 file HANDLE?

[Andrey Repin via Cygwin]

Greetings, Cedric Blancher!

> How can I convert a file descriptor from Cygwin openat() to Win32 file HANDLE?

In general, you should not attempt to do such thing.
If you have a very specific idea in mind, it would be best to describe, what
you are trying to achieve, so community could provide a more meaningful
suggestion to solve your specific issue.


-- 
With best regards,
Andrey Repin
Monday, March 4, 2024 11:19:58

Sorry for my terrible english...


-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple