Re: ExitProcess does not work in Cygwin?
On 2022-01-13 16:15, Jay K wrote:
On Thursday, January 13, 2022 5:19 PM, Brian Inglis wrote:
On 2022-01-13 10:07, Kaz Kylheku wrote:
On 2022-01-13 05:40, Eliot Moss wrote:
On 1/13/2022 1:39 AM, Jay K wrote:
ExitProcess does not work in Cygwin?
Just use POSIX exit(3)!
I did switch my code:
#ifdef __CYGWIN__
exit(x);
#else
ExitProcess(x);
#endif
.
I think the problem is actually in how "Cygwin bash"
aka Cygwin, computes the exit code in exec/spawn/system.
i.e. it recognizes it is running a Cygwin exe or a native
exe and does things differently.
...attempts to determine whether...
I admit I didn't read or debug much.
In one run I was debugging I did seem to see a crash
in some DllMain(process detach), without symbols, and then I seemed to see
ExitProcess(1 or 2) become ExitProcess(0xXX00) and
then I started wondering if Cygwin somewhere is only
taking the lower 8 bits, since I know that is a thing in some code.
Cygwin follows POSIX and returns only the lower eight bits ORed with the
child exit wait status flags (see wait(3p)) which may be tested with the
macros in sys/wait.h (see sys_wait.h(0p)).
But I didn't dig into this further before trying the simple case,
which I don't think crashes and really does NtTerminateProcess(1).
Just use POSIX exit(3)!
ExitProcess does not appear to be a POSIX function.
This is a real issue worth looking into. Though ExitProcess isn't a POSIX
function, Cygwin can capture the termination status of non-Cygwin programs.
The concept of termination status cannot be entirely walled off in a
private Cygwin garden; it belongs to the underlying platform.
You can do a lot of things under Cygwin, but only POSIX/Linux-like
operation should be expected; some other things work, but may not be
consistent, and are unlikely to be considered bugs e.g. using Windows
paths, TTY line terminators, or more than 8 bit exit codes.
In Cygwin, I can do this:
C:\Cygwin\cygwin64\home\kaz>exit 1
1:BLACKBOX:~$
1:BLACKBOX:~$ echo $?
1
0:BLACKBOX:~$ cmd
Microsoft Windows [Version 10.0.19042.1052]
(c) Microsoft Corporation. All rights reserved.
C:\Cygwin\cygwin64\home\kaz>exit 0
0:BLACKBOX:~$
The number in my Bash prompt is the last exit code. As you can see,
the non-Cygwin CMD.EXE program produces a termination code which
is recognized in the Cygwin world.
Most likely it does that via ExitProcess.
It is odd if calling ExitProcess in a Cygwin process causes
a Cygwin parent not to similarly process the status, as seems
to be shown by Jay's test cases.
Cygwin supports non-POSIX programming; you can write GUI applications
using Win32 calls for instance.
GUI e.g. Cygwin Setup program setup-x86/_64 and also Windows console
apps e.g. cygcheck, cygwin-console-helper, ldh, strace, but those are
all built with {i686,x86_64}-w64-mingw32-g++ and linked to MS msvcrt.dll
*NOT* Cygwin cygwin1.dll startup and runtime.
The default terminal console app mintty is a hybrid case.
(Now I agree that for exiting your process, even if it's a GUI
application using numerous win32 calls, you should probably do it the
Cygwin way, and use exit, or return from main. But still ...)
Cygwin installs at-exit handlers and it is likely that when these have
finished, they return a Cygwin exit status if passed by the POSIX
function, perhaps unless some error has occurred during at-exit handling.
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]
--
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: python-numpy (1.22.0-1) can't be imported
On Wed, Jan 12 2022, Marco Atzeri wrote: > On 12.01.2022 12:47, ggl329 wrote: >> Hi Marco, >> I upgraded python39-numpy to 1.22.0-1, and failed to import numpy. >> It seems that mtrand.cpython-39-x86_64-cygwin.dll does not have >> PyInit_mtrand. >> Could you check if numpy can be imported in your environment? >> > > working on it. > In theory I have not changed the build between the two versions > but there was a patch in 1.19.4-1 for similar issue. > > Regards > Marco I have the same problems with the distribution NumPy package, but I can use a locally-compiled NumPy with no patches. It doesn't look like your build has any patches either: https://cygwin.com/cgi-bin2/package-cat.cgi?file=x86_64%2Fpython-numpy-src%2Fpython-numpy-1.22.0-1-src=numpy so that's fun. Out of curiousity, what options are you passing for cpu-baseline and cpu-dispatch? https://numpy.org/devdocs/reference/simd/build-options.html I don't see the newest cygport in the Cygwin package repository. -- 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: proc_waiter: error on read of child wait pipe 0x0, Win32 error 6
On Thu, 13 Jan 2022 16:11:04 -0800
Mark Geisert wrote:
> Takashi Yano wrote:
> > On Wed, 12 Jan 2022 07:41:41 +0100
> > Marco Atzeri wrote:
> >> On 12.01.2022 07:27, Jay K wrote:
> >>> Ok, here is a small demonstration of the problem.
> >>>
> >>> #include
> >>> #include
> >>> #include
> >>>
> >>> unsigned __stdcall thread(void* p)
> >>> {
> >>> unsigned i;
> >>> for (i = 0; i < 100; ++i)
> >>> system("./a.exe");
> >>> return 0;
> >>> }
> >>>
> >>> int main()
> >>> {
> >>> unsigned i;
> >>> HANDLE threads[100] = {0};
> >>> FILE* f = fopen("a.c", "w");
> >>> fprintf(f, "int main() { return 0; }\n");
> >>> fclose(f);
> >>
> >>
> >> so you are mixing Cygwin and Windows calls ?
> >> That is looking for trouble.
> >>
> >> Or it is a tentative to produce a test case ?
> >
> > I found that the same happens even with pthread rather than
> > win32 thread functions.
> >
> > #include
> > #include
> >
> > void *thread(void *p)
> > {
> > system("true");
> > return NULL;
> > }
> >
> > int main()
> > {
> > int i;
> > pthread_t threads[2];
> >
> > for (i = 0; i < 2; i++)
> > pthread_create([i], NULL, thread, NULL);
> >
> > for (i = 0; i < 2; i++)
> > pthread_join(threads[i], NULL);
> >
> > return 0;
> > }
> >
> > Executing above code results in hang with message:
> >0 [waitproc] a 786 proc_waiter: error on read of child wait pipe
> > 0x0, Win32 error 6
> >
>
> POSIX does not require system() to be thread-safe. On Cygwin, it isn't.
> When I
> ran into this a while back, I implemented an application wrapper around
> system()
> to serialize calls. It's tricky because you want to serialize just the
> mechanism
> of system(), not the programs that the multiple system()s call.
Ah, indeed.
https://pubs.opengroup.org/onlinepubs/9699919799/functions/system.html
says:
"The system() function need not be thread-safe."
while Linux's system() is MT-safe.
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
Re: proc_waiter: error on read of child wait pipe 0x0, Win32 error 6
Takashi Yano wrote:
On Wed, 12 Jan 2022 07:41:41 +0100
Marco Atzeri wrote:
On 12.01.2022 07:27, Jay K wrote:
Ok, here is a small demonstration of the problem.
#include
#include
#include
unsigned __stdcall thread(void* p)
{
unsigned i;
for (i = 0; i < 100; ++i)
system("./a.exe");
return 0;
}
int main()
{
unsigned i;
HANDLE threads[100] = {0};
FILE* f = fopen("a.c", "w");
fprintf(f, "int main() { return 0; }\n");
fclose(f);
so you are mixing Cygwin and Windows calls ?
That is looking for trouble.
Or it is a tentative to produce a test case ?
I found that the same happens even with pthread rather than
win32 thread functions.
#include
#include
void *thread(void *p)
{
system("true");
return NULL;
}
int main()
{
int i;
pthread_t threads[2];
for (i = 0; i < 2; i++)
pthread_create([i], NULL, thread, NULL);
for (i = 0; i < 2; i++)
pthread_join(threads[i], NULL);
return 0;
}
Executing above code results in hang with message:
0 [waitproc] a 786 proc_waiter: error on read of child wait pipe 0x0,
Win32 error 6
POSIX does not require system() to be thread-safe. On Cygwin, it isn't. When I
ran into this a while back, I implemented an application wrapper around system()
to serialize calls. It's tricky because you want to serialize just the mechanism
of system(), not the programs that the multiple system()s call.
..mark
--
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: proc_waiter: error on read of child wait pipe 0x0, Win32 error 6
On Wed, 12 Jan 2022 07:41:41 +0100
Marco Atzeri wrote:
> On 12.01.2022 07:27, Jay K wrote:
> > Ok, here is a small demonstration of the problem.
> >
> > #include
> > #include
> > #include
> >
> > unsigned __stdcall thread(void* p)
> > {
> >unsigned i;
> >for (i = 0; i < 100; ++i)
> > system("./a.exe");
> >return 0;
> > }
> >
> > int main()
> > {
> > unsigned i;
> > HANDLE threads[100] = {0};
> > FILE* f = fopen("a.c", "w");
> > fprintf(f, "int main() { return 0; }\n");
> > fclose(f);
>
>
> so you are mixing Cygwin and Windows calls ?
> That is looking for trouble.
>
> Or it is a tentative to produce a test case ?
I found that the same happens even with pthread rather than
win32 thread functions.
#include
#include
void *thread(void *p)
{
system("true");
return NULL;
}
int main()
{
int i;
pthread_t threads[2];
for (i = 0; i < 2; i++)
pthread_create([i], NULL, thread, NULL);
for (i = 0; i < 2; i++)
pthread_join(threads[i], NULL);
return 0;
}
Executing above code results in hang with message:
0 [waitproc] a 786 proc_waiter: error on read of child wait pipe 0x0,
Win32 error 6
--
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: ExitProcess does not work in Cygwin?
> Just use POSIX exit(3)! I did switch my code: #ifdef __CYGWIN__ exit(x); #else ExitProcess(x); #endif . I think the problem is actually in how "Cygwin bash" aka Cygwin, computes the exit code in exec/spawn/system. I.e. it recognizes it is running a Cygwin exe or a native exe and does things differently. I admit I didn't read or debug much. In one run I was debugging I did seem to see a crash in some DllMain(process detach), without symbols, and then I seemed to see ExitProcess(1 or 2) become ExitProcess(0xXX00) and then I started wondering if Cygwin somewhere is only taking the lower 8 bits, since I know that is a thing in some code. But I didn't dig into this further before trying the simple case, which I don't think crashes and really does NtTerminateProcess(1). - Jay From: Brian Inglis Sent: Thursday, January 13, 2022 5:19 PM To: cygwin@cygwin.com Cc: Jay K Subject: Re: ExitProcess does not work in Cygwin? On 2022-01-13 10:07, Kaz Kylheku (Cygwin) wrote: > On 2022-01-13 05:40, Eliot Moss wrote: >> On 1/13/2022 1:39 AM, Jay K wrote: >>> ExitProcess does not work in Cygwin? Just use POSIX exit(3)! >> ExitProcess does not appear to be a POSIX function. > > This is a real issue worth looking into. Though ExitProcess isn't a POSIX > function, Cygwin can capture the termination status of non-Cygwin programs. > > The concept of termination status cannot be entirely walled off in a > private Cygwin garden; it belongs to the underlying platform. > > In Cygwin, I can do this: > >C:\Cygwin\cygwin64\home\kaz>exit 1 >1:BLACKBOX:~$ >1:BLACKBOX:~$ echo $? >1 >0:BLACKBOX:~$ cmd >Microsoft Windows [Version 10.0.19042.1052] >(c) Microsoft Corporation. All rights reserved. > >C:\Cygwin\cygwin64\home\kaz>exit 0 >0:BLACKBOX:~$ > > The number in my Bash prompt is the last exit code. As you can see, > the non-Cygwin CMD.EXE program produces a termination code which > is recognized in the Cygwin world. > > Most likely it does that via ExitProcess. > > It is odd if calling ExitProcess in a Cygwin process causes > a Cygwin parent not to similarly process the status, as seems > to be shown by Jay's test cases. > > Cygwin supports non-POSIX programming; you can write GUI applications > using Win32 calls for instance. > > (Now I agree that for exiting your process, even if it's a GUI > application using numerous win32 calls, you should probably do it the > Cygwin way, and use exit, or return from main. But still ...) Cygwin installs at-exit handlers and it is likely that when these have finished, they return a Cygwin exit status if passed by the POSIX function, perhaps unless some error has occurred during at-exit handling. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.] -- 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
Help with standalone samba SID-uid mapping
I'm trying to set up samba (standalone) following these instructions:
https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-samba
but I'm having no luck getting my samba user/groups to appear correctly using
the comment field as described in the document.
I'm using samba 4.13.14 on Ubuntu 20.04 with security = user (smbpasswd).
winbindd is not installed and I'm not using any LDAP or AD anywhere.
E.g. here is what is on the server (croehrig:croehrig = 601:601;
cristina:cristina = 603:603)
housesrv[3]% ls -l /House/Users
total 17
drwxr-xr-x 9 cristina cristina 22 Jan 12 16:06 cristina
drwxr-xr-x 30 croehrig croehrig 53 Jan 13 09:47 croehrig
Here are the ACLs and SIDs when looking on the windows client:
tyto[5]% icacls housesrv\\Users\\\*
\\housesrv\Users\cristina S-1-5-21-751087815-2087572193-42305691-1001:(F)
S-1-22-2-603:(RX)
Everyone:(RX)
\\housesrv\Users\croehrig S-1-5-21-751087815-2087572193-42305691-1000:(F)
S-1-22-2-601:(RX)
Everyone:(RX)
As you can see, the gid is mapping to the S-1-22-2- as described in the
document above, but
the uid is using a domain-specific SID with different RIDs.
On the windows client I have the same users and groups set up locally (SAM)
with appropriate SID mappings to the same uid/gids (601/603) in the Cygwin
/etc/passwd and /etc/group. This has all been working well to ensure e.g.
rsync preserves permissions and ownership between cygwin and Linux. (The
windows groups are called 'grp-croehrig' and 'grp-cristina' since windows users
and groups share a namespace, but they are mapped to 'croehrig' and 'cristina'
in /etc/group).
Here is how the SMB share looks under Cygwin:
tyto[6]% ls -l //housesrv/Users/
total 0
drwxr-xr-x 1 Unknown+User Unix_Group+603 0 Jan 12 16:06 cristina
drwxr-xr-x 1 Unknown+User Unix_Group+601 0 Jan 13 09:47 croehrig
tyto[7]% ls -ln //housesrv/Users/
total 0
drwxr-xr-x 1 4294967295 4278190683 0 Jan 12 16:06 cristina
drwxr-xr-x 1 4294967295 4278190681 0 Jan 13 09:47 croehrig
I have added the SAM desc/comment field as described in the document above:
i.e.
net localgroup grp-croehrig /comment:''
net user croehrig /comment:''
and restarted all Cygwin processes, but it doesn't seem to have any effect
('net user croehrig' shows the comment is indeed present). I guess I don't
understand how that comment field works.
Anyone have any advice?
Thanks,
-- Chris
--
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: -Wsign-conversion flag in gcc in cygwin.
On Thu, 13 Jan 2022 at 15:34, Amit wrote:
>
> Hi,
>
> When I compile "long x = strlen("abcde")" on a linux system with the
> following gcc flags -Wall -Wconversion, I get the following warning:
...
> warning: conversion to ‘long int’ from ‘size_t’ may change the sign of the
> result [-Wsign-conversion]
Which Linux system? I get the same result on Ubuntu (WSL)
$ cat conversion-warning.c
#include
int main()
{
long x = strlen("meow"); // compile with -Wall -Wconversion
return x;
}
$ gcc-10 -Wall -Wconversion conversion-warning.c
conversion-warning.c: In function ‘main’:
conversion-warning.c:6:12: warning: conversion from ‘long int’ to
‘int’ may change value [-Wconversion]
6 | return x;
|^
(Note, this is not the sign conversion from size_t to (signed) long,
but the truncation from long to int)
$ gcc-10 --version
gcc-10 (Ubuntu 10.3.0-1ubuntu1~20.04) 10.3.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gcc-10 -dumpmachine
x86_64-linux-gnu
Csaba
--
You can get very substantial performance improvements
by not doing the right thing. - Scott Meyers, An Effective C++11/14 Sampler
So if you're looking for a completely portable, 100% standards-conformant way
to get the wrong information: this is what you want. - Scott Meyers (C++TDaWYK)
--
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: renaming with mv over existing file leaves .cyg000000xyz files behind
On 13.01.2022 17:53, Ronald Hoogenboom wrote: Hi, Renaming with mv over existing file leaves .cyg00xyz files behind I have noticed this when renaming on a smb mounted directory (AKA network drive). cygwin version: 3.2.0(0.340/5/3) windows version: Server 2012 R2 mv version: (GNU coreutils) 8.26-2 samba server version: 3.0.33 (RHEL5) Regards, Ronald. it looks like a AntiVirus or other BLODA https://cygwin.com/faq/faq.html#faq.using.bloda is interfering with your installation. Probably they are blocking the file while Cygwin try to remove the temporary one. Regards Marco -- 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
character device canonical mode
Apparently Cygwin does not support canonical mode on serial devices. On
input canonical mode will wait for a newline before returning from a
read(). The bit is cleared/ignored by tcsetattr() as demonstrated by a
subsequent tcgetattr() in the test program below.
I am wondering if this is because of a fundamental difference between
the Windows serial device model and POSIX or just because the
appropriate mappings haven't been implemented. (I have studiously
avoided Windows programming for decades, and Cygwin has been my enabler!)
My test program:
#include
#include
#include
#include
#include
#include
void check_rv(int rv, const char *where) {
if (rv) {
printf("Error %s: %d %s\n", where, errno, strerror(errno));
exit(1);
}
}
int main(int argc, char **argv) {
termios termios_p;
if (argc != 2) {
printf("Must specify a serial device\n");
exit(1);
}
int fd = open(argv[1], O_RDWR | O_NONBLOCK);
check_rv(fd == -1, "opening serial device");
check_rv(tcgetattr(fd, _p), "from tcgetattr()");
printf("c_lflag = 0x%X after open\n", termios_p.c_lflag);
termios_p.c_lflag |= ICANON;
printf("c_lflag = 0x%X to pass to tcsetattr()\n", termios_p.c_lflag);
check_rv(tcsetattr(fd, TCSANOW, _p), "from tcsetattr()");
check_rv(tcgetattr(fd, _p), "from 2nd tcgetattr()");
printf("c_lflag = 0x%X after tcsetattr()\n", termios_p.c_lflag);
return 0;
}
--
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: ExitProcess does not work in Cygwin?
On 2022-01-13 10:07, Kaz Kylheku (Cygwin) wrote: On 2022-01-13 05:40, Eliot Moss wrote: On 1/13/2022 1:39 AM, Jay K wrote: ExitProcess does not work in Cygwin? Just use POSIX exit(3)! ExitProcess does not appear to be a POSIX function. This is a real issue worth looking into. Though ExitProcess isn't a POSIX function, Cygwin can capture the termination status of non-Cygwin programs. The concept of termination status cannot be entirely walled off in a private Cygwin garden; it belongs to the underlying platform. In Cygwin, I can do this: C:\Cygwin\cygwin64\home\kaz>exit 1 1:BLACKBOX:~$ 1:BLACKBOX:~$ echo $? 1 0:BLACKBOX:~$ cmd Microsoft Windows [Version 10.0.19042.1052] (c) Microsoft Corporation. All rights reserved. C:\Cygwin\cygwin64\home\kaz>exit 0 0:BLACKBOX:~$ The number in my Bash prompt is the last exit code. As you can see, the non-Cygwin CMD.EXE program produces a termination code which is recognized in the Cygwin world. Most likely it does that via ExitProcess. It is odd if calling ExitProcess in a Cygwin process causes a Cygwin parent not to similarly process the status, as seems to be shown by Jay's test cases. Cygwin supports non-POSIX programming; you can write GUI applications using Win32 calls for instance. (Now I agree that for exiting your process, even if it's a GUI application using numerous win32 calls, you should probably do it the Cygwin way, and use exit, or return from main. But still ...) Cygwin installs at-exit handlers and it is likely that when these have finished, they return a Cygwin exit status if passed by the POSIX function, perhaps unless some error has occurred during at-exit handling. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.] -- 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: ExitProcess does not work in Cygwin?
On 2022-01-13 05:40, Eliot Moss wrote: On 1/13/2022 1:39 AM, Jay K wrote: ExitProcess does not work in Cygwin? ExitProcess does not appear to be a POSIX function. This is a real issue worth looking into. Though ExitProcess isn't a POSIX function, Cygwin can capture the termination status of non-Cygwin programs. The concept of termination status cannot be entirely walled off in a private Cygwin garden; it belongs to the underlying platform. In Cygwin, I can do this: C:\Cygwin\cygwin64\home\kaz>exit 1 1:BLACKBOX:~$ 1:BLACKBOX:~$ echo $? 1 0:BLACKBOX:~$ cmd Microsoft Windows [Version 10.0.19042.1052] (c) Microsoft Corporation. All rights reserved. C:\Cygwin\cygwin64\home\kaz>exit 0 0:BLACKBOX:~$ The number in my Bash prompt is the last exit code. As you can see, the non-Cygwin CMD.EXE program produces a termination code which is recognized in the Cygwin world. Most likely it does that via ExitProcess. It is odd if calling ExitProcess in a Cygwin process causes a Cygwin parent not to similarly process the status, as seems to be shown by Jay's test cases. Cygwin supports non-POSIX programming; you can write GUI applications using Win32 calls for instance. (Now I agree that for exiting your process, even if it's a GUI application using numerous win32 calls, you should probably do it the Cygwin way, and use exit, or return from main. But still ...) -- 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
renaming with mv over existing file leaves .cyg000000xyz files behind
Hi, Renaming with mv over existing file leaves .cyg00xyz files behind I have noticed this when renaming on a smb mounted directory (AKA network drive). cygwin version: 3.2.0(0.340/5/3) windows version: Server 2012 R2 mv version: (GNU coreutils) 8.26-2 samba server version: 3.0.33 (RHEL5) Regards, Ronald. -- 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 setup] Show a MessageBox warning if running on a deprecated Windows version
Show a MessageBox warning if we are running on a Windows version which
we have deprecated Cygwin support for:
- Windows 6.0 (Windows Vista, Windows Server 2008)
- 32-bit Windows
This warning can be disabled with '--allow-unsupported-windows'.
---
Notes:
Not sure if this is needed, or maybe this is just annoying to the ~3% of
users who are running effected OSes. But maybe we want to annoy them
into doing something about it?
main.cc| 23 +++
res.rc | 2 ++
resource.h | 2 ++
3 files changed, 23 insertions(+), 4 deletions(-)
diff --git a/main.cc b/main.cc
index 162028f..818b01b 100644
--- a/main.cc
+++ b/main.cc
@@ -330,11 +330,26 @@ WinMain (HINSTANCE h,
}
/* Check if Cygwin works on this Windows version */
-if (!UnsupportedOption && (OSMajorVersion () < 6))
+if (!UnsupportedOption)
{
- mbox (NULL, IDS_UNSUPPORTED_WINDOWS_VERSION,
- MB_ICONEXCLAMATION | MB_OK);
- Logger ().exit (1, false);
+if (OSMajorVersion () < 6)
+ {
+mbox (NULL, IDS_UNSUPPORTED_WINDOWS_VERSION,
+ MB_ICONEXCLAMATION | MB_OK);
+Logger ().exit (1, false);
+ }
+
+if
+#ifdef _X86_
+ (TRUE)
+#else
+ (!is_64bit)
+#endif
+ mbox (NULL, IDS_DEPRECATED_WINDOWS_ARCH,
+MB_ICONEXCLAMATION | MB_OK);
+else if ((OSMajorVersion () == 6) && (OSMinorVersion() < 1))
+ mbox (NULL, IDS_DEPRECATED_WINDOWS_VERSION,
+MB_ICONEXCLAMATION | MB_OK);
}
/* Set default DACL and Group. */
diff --git a/res.rc b/res.rc
index 83d8339..1b9026a 100644
--- a/res.rc
+++ b/res.rc
@@ -675,6 +675,8 @@ BEGIN
"Setup will not be able to create Cygwin Icons "
"in the Start Menu or on the Desktop."
IDS_UNSUPPORTED_WINDOWS_VERSION "Cygwin is not supported on this Windows
version"
+IDS_DEPRECATED_WINDOWS_VERSION "Cygwin support for this Windows version is
deprecated, and will be removed in the next major version"
+IDS_DEPRECATED_WINDOWS_ARCH "Cygwin support for 32-bit Windows is
deprecated, and will be removed in the next major version"
IDS_MOUNT_REGISTRY_KEY_FAILED "Couldn't create registry key to store
installation path"
IDS_NIO_ERROR "Internet Error: %s"
IDS_PREREQ_UNSOLVED_PROBLEMS
diff --git a/resource.h b/resource.h
index 0a10f64..6dfedcc 100644
--- a/resource.h
+++ b/resource.h
@@ -103,6 +103,8 @@
#define IDS_PROGRESS_DOWNLOADING_FROM1206
#define IDS_FILE_INUSE_KILL 1207
#define IDS_FILE_INUSE_MSG 1208
+#define IDS_DEPRECATED_WINDOWS_VERSION 1209
+#define IDS_DEPRECATED_WINDOWS_ARCH 1210
// Dialogs
--
2.34.1
Re: [PATCH] fhandler_pipe: add sanity limit to handle loops
On 1/13/2022 5:56 AM, Takashi Yano wrote: Ken Brown wrote: 2. You can use the ReturnLength parameter of NtQueryInformationProcess to see how big a buffer is needed. This might be more efficient than repeatedly doubling the buffer size. Even if ReturnLength is used, the first NtQueryInformationProcess() call and the second NtQueryInformationProcess() call will not be done in atomic, so retrying is still necessary. However, it may be more efficient as you mentioned. The similar is true also for NtQuerySystemInformation(). Do you still think it is better to use ReturnLength rather than doubling the buffer? I'm not sure. I only mentioned it because I saw that that's what Process Hacker did, but still in a retry loop as you said. I suspect it doesn't make a lot of difference in practice, since we call the function once and then cache the value. Do whatever you think is best. Thanks. Ken -- 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
-Wsign-conversion flag in gcc in cygwin.
Hi,
When I compile "long x = strlen("abcde")" on a linux system with the
following gcc flags -Wall -Wconversion, I get the following warning:
==
size.c: In function ‘main’:
size.c:7:17: warning: conversion to ‘long int’ from ‘size_t’ may
change the sign of the result [-Wsign-conversion]
long x = strlen("abcde");
^
==
But on cygwin, I don't get this warning.
So, is -Wsign-conversion flag not implemented in gcc in cygwin?
--
$ gcc --version
gcc (GCC) 11.2.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gcc -dumpmachine
x86_64-pc-cygwin
--
Amit
--
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: proc_waiter: error on read of child wait pipe 0x0, Win32 error 6
On 1/13/2022 1:40 AM, Jay K wrote:
I don't know why I didn't get the reply in email, but this is representative of
the real world code.
- Jay
From: Jay K
Sent: Wednesday, January 12, 2022 6:27 AM
To: cyg...@sourceware.org
Subject: Re: proc_waiter: error on read of child wait pipe 0x0, Win32 error 6
Ok, here is a small demonstration of the problem.
#include
#include
#include
unsigned __stdcall thread(void* p)
{
unsigned i;
for (i = 0; i < 100; ++i)
system("./a.exe");
return 0;
}
int main()
{
unsigned i;
HANDLE threads[100] = {0};
FILE* f = fopen("a.c", "w");
fprintf(f, "int main() { return 0; }\n");
fclose(f);
system("g++ a.c");
for (i = 0; i < 100; ++i)
threads[i] = CreateThread(0, 0, thread, 0,0,0);
for (i = 0; i < 100; ++i)
WaitForSingleObject(threads[i], -1);
}
Again, Cygwin is designed to provide a POSIX-like interface.
Maybe you should just be using a Windows C compiler?
EM
--
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: ExitProcess does not work in Cygwin?
On 1/13/2022 1:39 AM, Jay K wrote:
ExitProcess does not work in Cygwin?
$ rm *.exe
# u is for Unix
# w is for Windows
$ cat u.c
#include
int main()
{
exit(1);
}
$ gcc u.c
$ ./a.exe
$ echo $?
1
=> as expected
$ cat w.c
#include
int main()
{
ExitProcess(1);
}
$ gcc w.c
$ ./a.exe
$ echo $?
0
=> not expected
$ uname -a
CYGWIN_NT-10.0 jayk-tp4 3.3.3(0.341/5/3) 2021-12-03 16:35 x86_64 Cygwin
works in debugger:
$ /cygdrive/c/bin/amd64/windbg.exe .\\a.exe
$ echo $?
1
?
- Jay
ExitProcess does not appear to be a POSIX function. Cygwin strives to provide a
POSIX-like interface, not a Windows-like one. However, if ExitProcess is a
Windows
function, there is probably a library you can use to obtain it in Cygwin (maybe
the winsup (Windows support) library).
Eliot Moss
--
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 3/4] Cygwin: pty: Stop closing and recreating attach_mutex.
- Closing attach_mutex and recreating it causes the race issue
between pty and console codes. With this patch, attach_mutex
is created only once in a process which opens pty, and never
closed in order to avoid this issue.
Addresses:
https://cygwin.com/pipermail/cygwin-developers/2021-December/012548.html
---
winsup/cygwin/fhandler.h | 3 +++
winsup/cygwin/fhandler_console.cc | 17 -
winsup/cygwin/fhandler_tty.cc | 30 --
winsup/cygwin/select.cc | 16
4 files changed, 23 insertions(+), 43 deletions(-)
diff --git a/winsup/cygwin/fhandler.h b/winsup/cygwin/fhandler.h
index 4f70c4c0b..0cea1b7f3 100644
--- a/winsup/cygwin/fhandler.h
+++ b/winsup/cygwin/fhandler.h
@@ -1881,6 +1881,9 @@ class fhandler_serial: public fhandler_base
#define release_output_mutex() \
__release_output_mutex (__PRETTY_FUNCTION__, __LINE__)
+DWORD acquire_attach_mutex (DWORD t);
+void release_attach_mutex (void);
+
class tty;
class tty_min;
class fhandler_termios: public fhandler_base
diff --git a/winsup/cygwin/fhandler_console.cc
b/winsup/cygwin/fhandler_console.cc
index 024be522b..0e4b41559 100644
--- a/winsup/cygwin/fhandler_console.cc
+++ b/winsup/cygwin/fhandler_console.cc
@@ -56,25 +56,8 @@ fhandler_console::console_state NO_COPY
*fhandler_console::shared_console_info;
bool NO_COPY fhandler_console::invisible_console;
-/* Mutex for AttachConsole()/FreeConsole() in fhandler_tty.cc */
-HANDLE attach_mutex;
-
extern DWORD mutex_timeout; /* defined in fhandler_termios.cc */
-static inline void
-acquire_attach_mutex (DWORD t)
-{
- if (attach_mutex)
-WaitForSingleObject (attach_mutex, t);
-}
-
-static inline void
-release_attach_mutex ()
-{
- if (attach_mutex)
-ReleaseMutex (attach_mutex);
-}
-
/* con_ra is shared in the same process.
Only one console can exist in a process, therefore, static is suitable. */
static struct fhandler_base::rabuf_t con_ra;
diff --git a/winsup/cygwin/fhandler_tty.cc b/winsup/cygwin/fhandler_tty.cc
index f68e80df9..1ae4edd63 100644
--- a/winsup/cygwin/fhandler_tty.cc
+++ b/winsup/cygwin/fhandler_tty.cc
@@ -58,8 +58,21 @@ struct pipe_reply {
DWORD error;
};
-extern HANDLE attach_mutex; /* Defined in fhandler_console.cc */
-static LONG master_cnt = 0;
+HANDLE attach_mutex;
+
+DWORD acquire_attach_mutex (DWORD t)
+{
+ if (!attach_mutex)
+return WAIT_OBJECT_0;
+ return WaitForSingleObject (attach_mutex, t);
+}
+
+void release_attach_mutex (void)
+{
+ if (!attach_mutex)
+return;
+ ReleaseMutex (attach_mutex);
+}
inline static bool pcon_pid_alive (DWORD pid);
@@ -523,13 +536,13 @@ fhandler_pty_master::accept_input ()
{
/* Slave attaches to a different console than master.
Therefore reattach here. */
- WaitForSingleObject (attach_mutex, mutex_timeout);
+ acquire_attach_mutex (mutex_timeout);
FreeConsole ();
AttachConsole (target_pid);
cp_to = GetConsoleCP ();
FreeConsole ();
AttachConsole (resume_pid);
- ReleaseMutex (attach_mutex);
+ release_attach_mutex ();
}
else
cp_to = GetConsoleCP ();
@@ -2111,8 +2124,6 @@ fhandler_pty_master::close ()
master_fwd_thread->detach ();
}
}
- if (InterlockedDecrement (_cnt) == 0)
-CloseHandle (attach_mutex);
/* Check if the last master handle has been closed. If so, set
input_available_event to wake up potentially waiting slaves. */
@@ -2838,13 +2849,13 @@ fhandler_pty_master::pty_master_fwd_thread (const
master_fwd_thread_param_t *p)
{
/* Slave attaches to a different console than master.
Therefore reattach here. */
- WaitForSingleObject (attach_mutex, mutex_timeout);
+ acquire_attach_mutex (mutex_timeout);
FreeConsole ();
AttachConsole (target_pid);
cp_from = GetConsoleOutputCP ();
FreeConsole ();
AttachConsole (resume_pid);
- ReleaseMutex (attach_mutex);
+ release_attach_mutex ();
}
else
cp_from = GetConsoleOutputCP ();
@@ -2993,7 +3004,7 @@ fhandler_pty_master::setup ()
if (!(pcon_mutex = CreateMutex (, FALSE, buf)))
goto err;
- if (InterlockedIncrement (_cnt) == 1)
+ if (!attach_mutex)
attach_mutex = CreateMutex (, FALSE, NULL);
/* Create master control pipe which allows the master to duplicate
@@ -3057,7 +3068,6 @@ err:
close_maybe (input_available_event);
close_maybe (output_mutex);
close_maybe (input_mutex);
- close_maybe (attach_mutex);
close_maybe (from_master_nat);
close_maybe (from_master);
close_maybe (to_master_nat);
diff --git a/winsup/cygwin/select.cc b/winsup/cygwin/select.cc
index 0cd62d932..5b8fc0f81 100644
--- a/winsup/cygwin/select.cc
+++ b/winsup/cygwin/select.cc
@@ -1095,22 +1095,6 @@ fhandler_fifo::select_except (select_stuff *ss)
return s;
}
-extern
[PATCH 4/4] Cygwin: console: Fix potential deadlock regarding acuqiring mutex.
- Acquiring input_mutex and attach_mutex in console code has potential
risk of deadlock. This patch fixes the issue.
---
winsup/cygwin/fhandler.h | 2 ++
winsup/cygwin/select.cc | 7 ---
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/winsup/cygwin/fhandler.h b/winsup/cygwin/fhandler.h
index 0cea1b7f3..fb4747608 100644
--- a/winsup/cygwin/fhandler.h
+++ b/winsup/cygwin/fhandler.h
@@ -2208,9 +2208,11 @@ private:
void acquire_input_mutex_if_necessary (DWORD ms)
{
acquire_input_mutex (ms);
+acquire_attach_mutex (ms);
}
void release_input_mutex_if_necessary (void)
{
+release_attach_mutex ();
release_input_mutex ();
}
diff --git a/winsup/cygwin/select.cc b/winsup/cygwin/select.cc
index 5b8fc0f81..d01a319ef 100644
--- a/winsup/cygwin/select.cc
+++ b/winsup/cygwin/select.cc
@@ -1122,29 +1122,30 @@ peek_console (select_record *me, bool)
HANDLE h;
set_handle_or_return_if_not_open (h, me);
+ fh->acquire_input_mutex (mutex_timeout);
acquire_attach_mutex (mutex_timeout);
while (!fh->input_ready && !fh->get_cons_readahead_valid ())
{
if (fh->bg_check (SIGTTIN, true) <= bg_eof)
{
release_attach_mutex ();
+ fh->release_input_mutex ();
return me->read_ready = true;
}
else if (!PeekConsoleInputW (h, , 1, _read) || !events_read)
break;
- fh->acquire_input_mutex (mutex_timeout);
if (fhandler_console::input_winch == fh->process_input_message ()
&& global_sigs[SIGWINCH].sa_handler != SIG_IGN
&& global_sigs[SIGWINCH].sa_handler != SIG_DFL)
{
set_sig_errno (EINTR);
- fh->release_input_mutex ();
release_attach_mutex ();
+ fh->release_input_mutex ();
return -1;
}
- fh->release_input_mutex ();
}
release_attach_mutex ();
+ fh->release_input_mutex ();
if (fh->input_ready || fh->get_cons_readahead_valid ())
return me->read_ready = true;
--
2.34.1
[PATCH 1/4] Cygwin: pty, console: Fix deadlock in GDB regarding mutex.
- GDB inferior may be suspended while the inferior grabs mutex.
This causes deadlock in terminal I/O. With this patch, timeout
for waiting mutex is set to 0 for the debugger process when the
process calls CreateProcess() with DEBUG_PROCESS flag to avoid
deadlock. This may cause the race issue in GDB, however, there
is no other way than that.
Addresses:
https://cygwin.com/pipermail/cygwin-developers/2021-December/012542.html
---
winsup/cygwin/fhandler_console.cc | 77 ---
winsup/cygwin/fhandler_termios.cc | 8 +++-
winsup/cygwin/fhandler_tty.cc | 63 ++---
winsup/cygwin/select.cc | 6 ++-
winsup/cygwin/spawn.cc| 8 ++--
winsup/cygwin/tty.cc | 6 ++-
6 files changed, 115 insertions(+), 53 deletions(-)
diff --git a/winsup/cygwin/fhandler_console.cc
b/winsup/cygwin/fhandler_console.cc
index 4c98b5355..024be522b 100644
--- a/winsup/cygwin/fhandler_console.cc
+++ b/winsup/cygwin/fhandler_console.cc
@@ -59,6 +59,8 @@ bool NO_COPY fhandler_console::invisible_console;
/* Mutex for AttachConsole()/FreeConsole() in fhandler_tty.cc */
HANDLE attach_mutex;
+extern DWORD mutex_timeout; /* defined in fhandler_termios.cc */
+
static inline void
acquire_attach_mutex (DWORD t)
{
@@ -214,7 +216,7 @@ fhandler_console::cons_master_thread (handle_set_t *p, tty
*ttyp)
continue;
}
- WaitForSingleObject (p->input_mutex, INFINITE);
+ WaitForSingleObject (p->input_mutex, mutex_timeout);
total_read = 0;
switch (cygwait (p->input_handle, (DWORD) 0))
{
@@ -474,7 +476,7 @@ fhandler_console::set_input_mode (tty::cons_mode m, const
termios *t,
const handle_set_t *p)
{
DWORD flags = 0, oflags;
- WaitForSingleObject (p->input_mutex, INFINITE);
+ WaitForSingleObject (p->input_mutex, mutex_timeout);
GetConsoleMode (p->input_handle, );
switch (m)
{
@@ -521,7 +523,7 @@ fhandler_console::set_output_mode (tty::cons_mode m, const
termios *t,
const handle_set_t *p)
{
DWORD flags = ENABLE_PROCESSED_OUTPUT | ENABLE_WRAP_AT_EOL_OUTPUT;
- WaitForSingleObject (p->output_mutex, INFINITE);
+ WaitForSingleObject (p->output_mutex, mutex_timeout);
switch (m)
{
case tty::restore:
@@ -626,7 +628,7 @@ fhandler_console::set_raw_win32_keyboard_mode (bool
new_mode)
void
fhandler_console::set_cursor_maybe ()
{
- acquire_attach_mutex (INFINITE);
+ acquire_attach_mutex (mutex_timeout);
con.fillin (get_output_handle ());
release_attach_mutex ();
/* Nothing to do for xterm compatible mode. */
@@ -635,7 +637,7 @@ fhandler_console::set_cursor_maybe ()
if (con.dwLastCursorPosition.X != con.b.dwCursorPosition.X ||
con.dwLastCursorPosition.Y != con.b.dwCursorPosition.Y)
{
- acquire_attach_mutex (INFINITE);
+ acquire_attach_mutex (mutex_timeout);
SetConsoleCursorPosition (get_output_handle (), con.b.dwCursorPosition);
release_attach_mutex ();
con.dwLastCursorPosition = con.b.dwCursorPosition;
@@ -742,7 +744,7 @@ wait_retry:
if (GetLastError () == ERROR_INVALID_HANDLE)
{ /* Confirm the handle is still valid */
DWORD mode;
- acquire_attach_mutex (INFINITE);
+ acquire_attach_mutex (mutex_timeout);
BOOL res = GetConsoleMode (get_handle (), );
release_attach_mutex ();
if (res)
@@ -754,8 +756,8 @@ wait_retry:
#define buf ((char *) pv)
int ret;
- acquire_input_mutex (INFINITE);
- acquire_attach_mutex (INFINITE);
+ acquire_input_mutex (mutex_timeout);
+ acquire_attach_mutex (mutex_timeout);
ret = process_input_message ();
release_attach_mutex ();
switch (ret)
@@ -1410,7 +1412,7 @@ fhandler_console::close ()
{
debug_printf ("closing: %p, %p", get_handle (), get_output_handle ());
- acquire_output_mutex (INFINITE);
+ acquire_output_mutex (mutex_timeout);
if (shared_console_info)
{
@@ -1463,13 +1465,13 @@ fhandler_console::ioctl (unsigned int cmd, void *arg)
int res = fhandler_termios::ioctl (cmd, arg);
if (res <= 0)
return res;
- acquire_output_mutex (INFINITE);
+ acquire_output_mutex (mutex_timeout);
switch (cmd)
{
case TIOCGWINSZ:
int st;
- acquire_attach_mutex (INFINITE);
+ acquire_attach_mutex (mutex_timeout);
st = con.fillin (get_output_handle ());
release_attach_mutex ();
if (st)
@@ -1529,7 +1531,7 @@ fhandler_console::ioctl (unsigned int cmd, void *arg)
DWORD n;
int ret = 0;
INPUT_RECORD inp[INREC_SIZE];
- acquire_attach_mutex (INFINITE);
+ acquire_attach_mutex (mutex_timeout);
if (!PeekConsoleInputW (get_handle (), inp, INREC_SIZE, ))
{
set_errno (EINVAL);
@@ -1588,7 +1590,7 @@ fhandler_console::tcflush (int queue)
if (queue
[PATCH 0/4] Some fixes for console and pty.
Takashi Yano (4): Cygwin: pty, console: Fix deadlock in GDB regarding mutex. Cygwin: pty: Fix memory leak in master_fwd_thread. Cygwin: pty: Stop closing and recreating attach_mutex. Cygwin: console: Fix potential deadlock regarding acuqiring mutex. winsup/cygwin/fhandler.h | 5 ++ winsup/cygwin/fhandler_console.cc | 92 +++--- winsup/cygwin/fhandler_termios.cc | 8 ++- winsup/cygwin/fhandler_tty.cc | 95 +++ winsup/cygwin/select.cc | 25 ++-- winsup/cygwin/spawn.cc| 8 ++- winsup/cygwin/tty.cc | 7 ++- winsup/cygwin/tty.h | 1 + 8 files changed, 146 insertions(+), 95 deletions(-) -- 2.34.1
[PATCH 2/4] Cygwin: pty: Fix memory leak in master_fwd_thread.
- If master_fwd_thread is terminated by cygthread::terminate_thread(),
the opportunity to release tmp_pathbuf is missed, resulting in a
memory leak. This patch fixes the issue.
---
winsup/cygwin/fhandler_tty.cc | 6 +-
winsup/cygwin/tty.cc | 1 +
winsup/cygwin/tty.h | 1 +
3 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/winsup/cygwin/fhandler_tty.cc b/winsup/cygwin/fhandler_tty.cc
index 16dbc5c0a..f68e80df9 100644
--- a/winsup/cygwin/fhandler_tty.cc
+++ b/winsup/cygwin/fhandler_tty.cc
@@ -2106,7 +2106,9 @@ fhandler_pty_master::close ()
master_ctl = NULL;
}
release_output_mutex ();
- master_fwd_thread->terminate_thread ();
+ get_ttyp ()->stop_fwd_thread = true;
+ WriteFile (to_master_nat, "", 0, NULL, NULL);
+ master_fwd_thread->detach ();
}
}
if (InterlockedDecrement (_cnt) == 0)
@@ -2695,6 +2697,8 @@ fhandler_pty_master::pty_master_fwd_thread (const
master_fwd_thread_param_t *p)
termios_printf ("ReadFile for forwarding failed, %E");
break;
}
+ if (p->ttyp->stop_fwd_thread)
+ break;
ssize_t wlen = rlen;
char *ptr = outbuf;
if (p->ttyp->pcon_activated)
diff --git a/winsup/cygwin/tty.cc b/winsup/cygwin/tty.cc
index e29d73dcb..789528856 100644
--- a/winsup/cygwin/tty.cc
+++ b/winsup/cygwin/tty.cc
@@ -254,6 +254,7 @@ tty::init ()
last_sig = 0;
mask_flusho = false;
discard_input = false;
+ stop_fwd_thread = false;
}
HANDLE
diff --git a/winsup/cygwin/tty.h b/winsup/cygwin/tty.h
index 25d351a4a..519d7c0d5 100644
--- a/winsup/cygwin/tty.h
+++ b/winsup/cygwin/tty.h
@@ -132,6 +132,7 @@ private:
xfer_dir pcon_input_state;
bool mask_flusho;
bool discard_input;
+ bool stop_fwd_thread;
public:
HANDLE from_master_nat () const { return _from_master_nat; }
--
2.34.1
Re: [PATCH] fhandler_pipe: add sanity limit to handle loops
I am sorry for being absent for a long time. On Sun, 26 Dec 2021 10:09:57 -0500 Ken Brown wrote: > On 12/25/2021 11:56 PM, Jeremy Drake wrote: > > I set up a windows server 2022 VM last night and went nuts stressing > > pacman/GPGME. I was able to reproduce the issue there: > > > > status = 0x, phi->NumberOfHandles = 8261392, n_handle = 256 > > [#--] 14% > > assertion "phi->NumberOfHandles <= n_handle" failed: file > > "../../.././winsup/cygwin/fhandler_pipe.cc", line 1281, function: void* > > fhandler_pipe::get_query_hdl_per_process(WCHAR*, OBJECT_NAME_INFORMATION*) > > > > So it is not something inherent in the x86_64-on-ARM64 emulation but can > > happen on native x86_64 also. > > A Google search led me to something that might explain what's going on. Look > at > the function PhEnumHandlesEx2 starting at line 5713 in > > > https://github.com/processhacker/processhacker/blob/master/phlib/native.c#L5152 Thank you very much for finding this, > Two interesting things: > > 1. For some processes, NtQueryInformationProcess(ProcessHandleInformation) > can > return STATUS_SUCCESS with invalid handle information. See the comment > starting > at line 5754, where it is shown how to detect this. and also applying the fix. > 2. You can use the ReturnLength parameter of NtQueryInformationProcess to see > how big a buffer is needed. This might be more efficient than repeatedly > doubling the buffer size. Even if ReturnLength is used, the first NtQueryInformationProcess() call and the second NtQueryInformationProcess() call will not be done in atomic, so retrying is still necessary. However, it may be more efficient as you mentioned. The similar is true also for NtQuerySystemInformation(). Do you still think it is better to use ReturnLength rather than doubling the buffer? -- 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
add the ssh key in cygwin-developers
I would like to include my ssh key in the git repository. My ssh key is BEGIN SSH2 PUBLIC KEY ssh-rsa B3NzaC1yc2EDAQABAAABgQCxSzxyEOCu/arRDjniYZQN8vz2q2cmX52hefW+9TXSH3D28FIrXQ/KEZYu9y5XAAGi/lLx9Sps9/aWIKYZCVJN6tYdD9UcVqDc0gvOKZgwN+BRuWNnM/rXcW+Cdx3dyYlbcHWovmVZCafsod9LS4CjJdeJR753CJXTRYA47vUzw+kTYbmcpKFigoNjcwlUEJL58CSQ9WlzGJnsfxLPqJS9aPdTCU4TDATiPNLQAJZ0kghLk08nnB7mbdxoBvvR4pHPCFuprN3iukPGhizsyRbh8kKS1VNjPhK6jpTQUgHy63wsDtVCgL4GSLCCxR3ul+jSSXvmXO6xgxCWJi0Vom5xfR0kDz5qSkLrKfkW5kjscGV1aIMui//2I41THHoU7ZGkkzrEzwWxl09bFRgSY3qgNymGdjvD1DIh5ccoMjgf9yJBXxW4AizdVO7GQmBbQ3dyvpMG/OoO4B6miQMg+P2fQBtEw1J1S4hUM6zTig14CgPTML9Q2jXyyUGxujJ66L0= MRLUC@DESKTOP-LIGB845 END SSH2 PUBLIC KEY -- 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
