Re: python fails asyncio tests (py 3.7 & 3.8)
[Replying to myself...] Mark Geisert wrote: Jim Bell wrote: On 2020-11-21 5:59 AM, Jim Bell wrote: The standard python asyncio tests hang. cd /usr/lib/python3.8/test python3.8 test_asyncore.py -v [...] Using strace, stripping down this very repeatable test, and grabbing the source-code snapshot, it looks like winsup/cygwin/select.cc socket_cleanup() is waiting forever for the thread to go away. strace: 121 6732185 [main] python3.8 13329 select_stuff::cleanup: calling cleanup rout ines 178 6732363 [main] python3.8 13329 socket_cleanup: si 0x800290E10 si->thread 0 x18023E758 - [...] Thanks for the report and especially for the initial debugging you've done. I've reproduced the issue on my test machine. No need to supply 'cygcheck -svr' at this point. I'll investigate this further and keep you posted (on the Cygwin mailing list). The problem is actually further down in the guts of Cygwin's Unix Domain Socket handling. Specifically it has to do with the credential passing between client and server ends of a connection as part of its setup. There is a workaround for this problem that involves turning off socket option SO_PEERCRED on both the connecting and listening sockets. Unfortunately there's another problem. With the current Cygwin DLL build you'll get an EINVAL error trying to do that setsockopt() operation. I have submitted a patch that fixes this 2nd problem. A future Cygwin snapshot TBA will contain this patch. As for the test script errors you reported, I can submit a workaround patch that would make its way into the Python3.8 tests. I am unsure at the moment which Cygwin package contains those tests but I can figure that out. Otherwise, I could tell you what needs to be patched in test_asyncore.py and you could edit the script yourself to fix this locally for yourself. Let me know how you'd like to proceed, when you have a chance. ..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: Workaround for cygwin's way of linking folders?
On 2020/12/06 14:41, Johnathan Schneider via Cygwin wrote: Hi all, I'm setting up a cross platform development environment using Cygwin. Upon attempting to use Cygwin's CMake that is natively bundled, I discovered that Cygwin goes looking for the gcc in /usr/bin/cc, If you go into 'bash' under cygwin, what do you see in /usr/bin? /usr/bin is only a valid path inside programs that are running on cygwin -- if you run programs outside of cygwin, say directly from Windows, they won't see them. Cmake would likely be in the same folder as gcc. How are you invoking Cmake? If you are running cmake from, say, the cygwin path of /bin (assuming you have cygwin installed at C:\ and have your cygwin mount prefix set to '/'. In bash, type mount -p and you should see something like: mount -p Prefix Type Flags / user binmode Just like windows has various magic folders that show up under explorer, but don't really exist, cygwin does too, but only cygwin utils see the cygwin-folders. FWIW, /bin from a cygwin install is mounted (within cygwin) on /usr/bin, so the contents should be the same. If you want to make use of windows+cygwin at the same time, it's best to install cygwin at 'C:\' and set you mount prefix like I have above, then you will get more commonality between windows+cygwin. For example, to make /usr/bin appear under window, I have a symlink at C:/usr/bin that points to C:/bin. Under windows, a 'dir' of C:\usr will show (from cmd.exe, some lines removed for brevity): C:\Users\linda>dir \usr Volume in drive C is System Disk Directory of C:\usr 2020/05/17 17:11 . 2020/05/17 17:11 .. 2018/05/19 09:42 bin [..\bin] 2020/10/07 09:35 include 2018/05/19 09:41 lib [..\lib] 2018/05/17 11:20 lib64 [..\lib] 2020/12/06 23:25 sbin [..\sbin] 2020/11/03 20:38 share 2020/10/07 08:37 src 2020/05/17 17:11 x86_64-pc-cygwin 0 File(s) 0 bytes 17 Dir(s) 150,639,538,176 bytes free Alas, my question - what is the recommended workaround? --- Look for cygwin paths from a cygwin shell. That's the start. Making win+cyg play nice, involves little bits like symlinks like I used above. It's not officially supported by the cygwin, but I find such things convenient. -- 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: Allow to set SO_PEERCRED zero
The existing code errors as EINVAL any attempt to set a value for SO_PEERCRED via setsockopt() on an AF_UNIX/AF_LOCAL socket. But to enable the workaround set_no_getpeereid behavior for Python one has to be able to set SO_PEERCRED to zero. Ergo, this patch. Python has no way to specify a NULL pointer for 'optval'. --- winsup/cygwin/fhandler_socket_local.cc | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/winsup/cygwin/fhandler_socket_local.cc b/winsup/cygwin/fhandler_socket_local.cc index c94bf828f..421b8bbdb 100644 --- a/winsup/cygwin/fhandler_socket_local.cc +++ b/winsup/cygwin/fhandler_socket_local.cc @@ -1430,7 +1430,8 @@ fhandler_socket_local::setsockopt (int level, int optname, const void *optval, FIXME: In the long run we should find a more generic solution which doesn't require a blocking handshake in accept/connect to exchange SO_PEERCRED credentials. */ - if (optval || optlen) + /* Temporary: Allow only '(int) 0' to be specified. */ + if (optlen < (socklen_t) sizeof (int) || 0 != *(int *) optval) set_errno (EINVAL); else ret = af_local_set_no_getpeereid (); -- 2.29.2
[PATCH] Cygwin: Launch cygmagic with bash, not sh
On some systems /bin/sh is not /bin/bash and cygmagic has bash-isms in
it. So even though cygmagic has a /bin/bash shebang, it also needs to be
launched with bash from within Makefile.in.
---
winsup/cygwin/Makefile.in | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/winsup/cygwin/Makefile.in b/winsup/cygwin/Makefile.in
index b15c746cf..a840f2b83 100644
--- a/winsup/cygwin/Makefile.in
+++ b/winsup/cygwin/Makefile.in
@@ -683,10 +683,10 @@ globals.h: mkglobals_h globals.cc
${DLL_OFILES} ${LIBCOS}: globals.h $(srcdir)/$(TLSOFFSETS_H)
shared_info_magic.h: cygmagic shared_info.h
- /bin/sh $(word 1,$^) $@ "${COMPILE.cc} -E -x c++" $(word 2,$^)
SHARED_MAGIC 'class shared_info' USER_MAGIC 'class user_info'
+ /bin/bash $(word 1,$^) $@ "${COMPILE.cc} -E -x c++" $(word 2,$^)
SHARED_MAGIC 'class shared_info' USER_MAGIC 'class user_info'
child_info_magic.h: cygmagic child_info.h
- /bin/sh $(word 1,$^) $@ "${COMPILE.cc} -E -x c++" $(word 2,$^)
CHILD_INFO_MAGIC 'class child_info'
+ /bin/bash $(word 1,$^) $@ "${COMPILE.cc} -E -x c++" $(word 2,$^)
CHILD_INFO_MAGIC 'class child_info'
dcrt0.o sigproc.o: child_info_magic.h
--
2.29.2
Re: blockdev.exe is missing in util-linux. How to determine block device size in bash?
On Sat, Dec 05, 2020 at 12:43:25PM +0300, cygwin wrote: > Strange. On Win7 this doesn't work: > > il@mar2 /cygdrive/c/Windows/System32 > $ cat /proc/partitions > major minor #blocks name win-mounts > > 8 0 0 sda > 816 0 sdb > > il@mar2 /cygdrive/c/Windows/System32 > $ dd of=/dev/null if=/dev/sda bs=1M count=100 > 100+0 records in > 100+0 records out > 104857600 bytes (105 MB, 100 MiB) copied, 0.215181 s, 487 MB/s > > > On 28.11.2020 20:04, Brian Inglis wrote: > > $ cat /proc/partitions > > major minor #blocks name win-mounts > > > > 8 0 976762584 sda > > 8 1 16384 sda1 > > 8 2 97678 sda2 C:\ > > 816 976762584 sdb > > 817131072 sdb1 > > 818102400 sdb2 > > 819 975482161 sdb3 D:\ > > 820577536 sdb4 > > 821465920 sdb5 > > 832 0 sdc WFFM with Win7 Home 12:34:05$ cat /proc/partitions major minor #blocks name win-mounts 8 0 488386584 sda 8 1203776 sda1 8 2 467246080 sda2 C:\ 8 3 20829184 sda3 D:\ 8 4105472 sda4 F:\ Cheers ... Duncan. -- 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: Workaround for cygwin's way of linking folders?
On 12/6/2020 6:45 PM, Ken Brown via Cygwin wrote: On 12/6/2020 5:41 PM, Johnathan Schneider via Cygwin wrote: Hi all, I'm setting up a cross platform development environment using Cygwin. Upon attempting to use Cygwin's CMake that is natively bundled, I discovered that Cygwin goes looking for the gcc in /usr/bin/cc, a folder that does not exist according to windows. I have familiarized myself with the Cygwin way of organizing it's folders, seen here https://cygwin.com/faq.html#faq.using.shortcuts and https://cygwin.com/faq.html#faq.using.directory-structure and thus I know that Cygwin's /usr/bin folder is in fact /bin - according to windows, anyways. However, I'm not familiar with how to work around that on windows. In particular, virtually all of my IDEs' attempts to call CMake fail, because I proceed to ask it to call the gcc and windows, as is explained in the above FAQ's, does not recognize the Cygwin-way of referencing folders. Alas, my question - what is the recommended workaround? It's hard to answer this question without knowing exactly what your IDE is doing. Can you give a detailed recipe for reproducing the problem without using an IDE? In general, Cygwin's CMake should have no problem executing /usr/bin/cc unless something is interfering with Cygwin's normal path handling routines. My guess: Your IDE is Windows based, and it is unlikely to play well with Cygwin. It probably expects Windows paths, etc. MinGW might gives Unix-like tools that work better for you, or you can find Windows based CMake, C compilers, etc. With some effort, you _might_ get the IDEA to invoke the Cygwin program by giving the full Windows path to it, but /usr/bin/cc is going to expect Cygwin format paths, which a Windows based IDE won't know anything about ... My guess could be wrong, of course! Regards - 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: Workaround for cygwin's way of linking folders?
On 12/6/2020 5:41 PM, Johnathan Schneider via Cygwin wrote: Hi all, I'm setting up a cross platform development environment using Cygwin. Upon attempting to use Cygwin's CMake that is natively bundled, I discovered that Cygwin goes looking for the gcc in /usr/bin/cc, a folder that does not exist according to windows. I have familiarized myself with the Cygwin way of organizing it's folders, seen here https://cygwin.com/faq.html#faq.using.shortcuts and https://cygwin.com/faq.html#faq.using.directory-structure and thus I know that Cygwin's /usr/bin folder is in fact /bin - according to windows, anyways. However, I'm not familiar with how to work around that on windows. In particular, virtually all of my IDEs' attempts to call CMake fail, because I proceed to ask it to call the gcc and windows, as is explained in the above FAQ's, does not recognize the Cygwin-way of referencing folders. Alas, my question - what is the recommended workaround? It's hard to answer this question without knowing exactly what your IDE is doing. Can you give a detailed recipe for reproducing the problem without using an IDE? In general, Cygwin's CMake should have no problem executing /usr/bin/cc unless something is interfering with Cygwin's normal path handling routines. 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
Workaround for cygwin's way of linking folders?
Hi all, I'm setting up a cross platform development environment using Cygwin. Upon attempting to use Cygwin's CMake that is natively bundled, I discovered that Cygwin goes looking for the gcc in /usr/bin/cc, a folder that does not exist according to windows. I have familiarized myself with the Cygwin way of organizing it's folders, seen here https://cygwin.com/faq.html#faq.using.shortcuts and https://cygwin.com/faq.html#faq.using.directory-structure and thus I know that Cygwin's /usr/bin folder is in fact /bin - according to windows, anyways. However, I'm not familiar with how to work around that on windows. In particular, virtually all of my IDEs' attempts to call CMake fail, because I proceed to ask it to call the gcc and windows, as is explained in the above FAQ's, does not recognize the Cygwin-way of referencing folders. Alas, my question - what is the recommended workaround? -- 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: Unix Domain Socket Limitation?
On 12/6/2020 12:17 PM, Norton Allen wrote: On 12/5/2020 6:52 PM, Ken Brown wrote: On 12/4/2020 8:51 AM, Norton Allen wrote: On 12/3/2020 8:11 PM, Ken Brown wrote: I'm traveling at the moment and unable to do any testing, but I wonder if you're bumping into an issue that was just discussed on the cygwin-developers list: https://cygwin.com/pipermail/cygwin-developers/2020-December/012015.html A different workaround is described there. If it's the same issue, then I don't think it will happen with the new AF_UNIX implementation. More in a few days. It does seem related. A work around that is working for me is to do a blocking connect() and switch to non-blocking when that completes. In my application, the connect() generally occurs once at the beginning of a run, so blocking for a few milliseconds does not impact responsiveness. For the record, I can confirm that (a) the problem occurs with the current AF_UNIX implementation and (b) it does not occur with the new implementation (on the topic/af_unix branch). With both client1 and client2, I see "connect() apparently succeeded immediately" using the new implementation. The new implementation is not yet ready for prime time, but with any luck it might be ready within a few months. That sounds great, and exactly like the behavior under Linux. I'd certainly be happy to test the new implementation as it gets closer, and also happy to expand or improve the test apps to cover a wider range of functionality and/or usability (e.g. run both client and server via a fork.) Feel free to let me know what would be particularly useful. Thanks. I'll take you up on that when the branch is in slightly better shape. 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
Re: Unix Domain Socket Limitation?
On 12/5/2020 6:52 PM, Ken Brown wrote: On 12/4/2020 8:51 AM, Norton Allen wrote: On 12/3/2020 8:11 PM, Ken Brown wrote: I'm traveling at the moment and unable to do any testing, but I wonder if you're bumping into an issue that was just discussed on the cygwin-developers list: https://cygwin.com/pipermail/cygwin-developers/2020-December/012015.html A different workaround is described there. If it's the same issue, then I don't think it will happen with the new AF_UNIX implementation. More in a few days. It does seem related. A work around that is working for me is to do a blocking connect() and switch to non-blocking when that completes. In my application, the connect() generally occurs once at the beginning of a run, so blocking for a few milliseconds does not impact responsiveness. For the record, I can confirm that (a) the problem occurs with the current AF_UNIX implementation and (b) it does not occur with the new implementation (on the topic/af_unix branch). With both client1 and client2, I see "connect() apparently succeeded immediately" using the new implementation. The new implementation is not yet ready for prime time, but with any luck it might be ready within a few months. That sounds great, and exactly like the behavior under Linux. I'd certainly be happy to test the new implementation as it gets closer, and also happy to expand or improve the test apps to cover a wider range of functionality and/or usability (e.g. run both client and server via a fork.) Feel free to let me know what would be particularly useful. -- 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
[ANNOUNCEMENT] Updated: mingw64-{i686,x86_64}-gcc-10.2.0-1
The latest mingw-w64 cross compilers have been promoted from test to current: * mingw64-i686-gcc-10.2.0-1 * mingw64-x86_64-gcc-10.2.0-1 -- *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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
Updated: mingw64-{i686,x86_64}-gcc-10.2.0-1
The latest mingw-w64 cross compilers have been promoted from test to current: * mingw64-i686-gcc-10.2.0-1 * mingw64-x86_64-gcc-10.2.0-1 -- *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL.
