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
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
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
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
-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: [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
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
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
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
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, &termios_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, &termios_p), "from tcsetattr()"); check_rv(tcgetattr(fd, &termios_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: 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
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
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: 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
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(&threads[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: 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(&threads[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 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(&threads[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: 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&grep=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: 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