Re: cygwin application hangs on closing console
Hi List,
We did more testing and it looks like the name of the event
that signals console master thread start and end is shared between
unrelated processes (it uses the console minor which is always (?)
0 when running from a powershell).
So since it is a two-state event (as opposed to a semaphore)
in theory the following can happen:
Process A Process B
SetEvent(e)
SetEvent(e)
Waitforevent(e)
Waitforevent(e)
The second SetEvent does nothing. As a result the
later Waitforevent is stuck (which is what we observe).
So the question is: why should this event be used in
unrelated cygwin processes? Is there a technical reason
we don't understand (yet) for doing that (sharing the event).
We patched cygwin to use pseudo random event names (the
tm_usec field of gettimeofday()) and the stuckness vanished.
So unless there is a reason for sharing the event between
cygwin processes this patch should work:
From f2e2d125a21487579ecb9173406c6322ee4ecfeb Mon Sep 17 00:00:00 2001
From: Johannes Thoma
Date: Wed, 29 May 2024 17:35:35 +
Subject: [PATCH] console: use pseudo random thread_sync_event name
---
winsup/cygwin/fhandler/console.cc | 9 +++--
winsup/cygwin/local_includes/fhandler.h | 1 +
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/winsup/cygwin/fhandler/console.cc
b/winsup/cygwin/fhandler/console.cc
index 1352482e9..d9c88d245 100644
--- a/winsup/cygwin/fhandler/console.cc
+++ b/winsup/cygwin/fhandler/console.cc
@@ -1895,7 +1895,12 @@ debug_printf("myself->pid %d con.owner %d\n",
myself->pid, con.owner);
if (GetModuleHandle ("ConEmuHk64.dll"))
hook_conemu_cygwin_connector ();
char name[MAX_PATH];
- shared_name (name, CONS_THREAD_SYNC, get_minor ());
+
+ struct timeval v;
+ gettimeofday(&v, NULL);
+ a_random_number = v.tv_usec;
+
+ shared_name (name, CONS_THREAD_SYNC, a_random_number);
thread_sync_event = CreateEvent(NULL, FALSE, FALSE, name);
@@ -1983,7 +1988,7 @@ debug_printf("%s: 1\n", __func__);
char name[MAX_PATH];
- shared_name (name, CONS_THREAD_SYNC, get_minor ());
+ shared_name (name, CONS_THREAD_SYNC, a_random_number);
thread_sync_event = OpenEvent (MAXIMUM_ALLOWED, FALSE, name);
diff --git a/winsup/cygwin/local_includes/fhandler.h
b/winsup/cygwin/local_includes/fhandler.h
index 978d3e514..132dc6477 100644
--- a/winsup/cygwin/local_includes/fhandler.h
+++ b/winsup/cygwin/local_includes/fhandler.h
@@ -2215,6 +2215,7 @@ public:
};
typedef cons_handle_set_t handle_set_t;
HANDLE thread_sync_event;
+ int a_random_number;
private:
static const unsigned MAX_WRITE_CHARS;
static console_state *shared_console_info[MAX_CONS_DEV + 1];
--
2.17.1
--
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
cleanup of in-use files moved to recycle bin
I'm not necessarily sure that the subject is clear enough, so I want to be explicit that I'm talking about files (or I guess potentially directories, though I've never seen that) generated by the `try_to_bin` function in winsup/cygwin/syscalls.cc. Specifically, you can generate one with this simple bash reproducer: cp /usr/bin/sleep.exe . ./sleep 1000 & rm -f ./sleep.exe kill %1 fg My questions are (starting at the beginning with what I'm trying to accomplish, and wandering off into the weeds of the various things I've tried to do that). 1) is there some mechanism in Cygwin that I'm not seeing to clean up these files? So far I've confirmed that their creation does not result in the recycle bin icon turning from 'empty' to 'full' on the desktop, and that emptying the recycle bin there (when it doesn't think it's already empty) does not remove them. 2) assuming there is not, I want to make a script using only things present in a "base system" to clean them up. This isn't too horribly difficult, using bash and find, *if I can assume that all Windows volumes are rooted at drive letters*. Once I take into account Windows folder-mounted volumes, I need to be able to find a list of all volume roots, in a safe way. I hacked together a sed script that parses the output of `mountvol`, but that is clearly not safe (not only did it rely on a message that is likely translated, but mountvol seems to switch to ANSI output when it is piped or redirected, and any unicode characters turn into '_') [1]. I made a C program to do this [2], and that's fine, except I really wanted to avoid having to ship a new binary. Is there any way in Cygwin to get this list? Maybe this is something that should be added to cygpath? 3) in furtherance of figuring that out, I started grepping around for FindNextVolumeW and GetVolumePathNamesForVolumeNameW in cygwin, and found the dos_drive_mappings class in winsup/cygwin/mount.cc. This is sort-of exposed via the cygwin_internal function CW_ALLOC_DRIVE_MAP, though the type itself is not. As a proof-of-concept hack, I wrote another C program based on this [3], but I don't think that really helps anything. 4) while pondering this, I keep coming back to the idea that volume folder mounts could be exposed via the 'normal' mount interface, such as `getmntent`, `/proc/self/mounts`, `/proc/self/mountinfo`), as children of the drive-letter cygdrive mounts. This would make getting the list of mounts safely a solved problem(*), and would probably also have the bonus effect of letting `df` list their free space. Is there a good reason that this is not already done (other than SHTDI)? * I found a bug/limitation here, which I will report in a separate email, because that doesn't depend on any of this. 5) in addition, I ported the C example programs to python ctypes, and factored out to a small module [4], but that also doesn't really help, because python is not part of the "base system". But it might be useful to somebody else, so I link to it here too. [1]: https://github.com/msys2/MSYS2-packages/issues/4622#issuecomment-2140990166 [2]: https://gist.github.com/jeremyd2019/8e088a72dfef44ee29ed3442957c1e65 [3]: https://gist.github.com/jeremyd2019/ac2f00ec448e75c4bd3630926201db19 [4]: https://gist.github.com/jeremyd2019/95c2cfd7eef2ed29a339860896deddec -- 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
mount points with whitespace are not escaped
Steps to reproduce: $ mkdir /$'My New\r\nFolder' $ mount c: /$'My New\r\nFolder' $ mount C:/cygwin64/bin on /usr/bin type ntfs (binary,auto) C:/cygwin64/lib on /usr/lib type ntfs (binary,auto) C:/cygwin64 on / type ntfs (binary,auto) C: on /My New Folder type ntfs (binary,user) $ cat /proc/self/mounts C:/cygwin64/bin /usr/bin ntfs binary,auto 1 1 C:/cygwin64/lib /usr/lib ntfs binary,auto 1 1 C:/cygwin64 / ntfs binary,auto 1 1 C: /My New Folder ntfs binary,user 1 1 $ cat /proc/self/mountinfo 0 0 39488:20815 / /usr/bin binary,auto - ntfs C:/cygwin64/bin rw 1 1 39488:20815 / /usr/lib binary,auto - ntfs C:/cygwin64/lib rw 2 2 39488:20815 / / binary,auto - ntfs C:/cygwin64 rw 3 3 39488:20815 / /My New Folder binary,user - ntfs C: rw Expected (what happens on Linux) is that mount outputs the \r\n as ??, but /proc/self/mounts and /proc/self/mountinfo use octal escapes for ' ' and \n (I was rather surprised they didn't escape \r also, but I guess they don't have to because only ' ' and \n are used as delimiters): $ mount ... /dev/mapper/XXX on /My New??Folder type ext3 (rw,noatime,data=ordered) $ cat /proc/self/mounts | xxd ... 0400: 6564 2030 2030 0a2f 6465 762f 646d 2d30 ed 0 0./dev/dm-0 0410: 202f 4d79 5c30 3430 4e65 770d 5c30 3132 /My\040New.\012 0420: 466f 6c64 6572 2065 7874 3320 7277 2c6e Folder ext3 rw,n 0430: 6f61 7469 6d65 2c64 6174 613d 6f72 6465 oatime,data=orde 0440: 7265 6420 3020 300a red 0 0. $ cat /proc/self/mountinfo | xxd ... 04f0: 2f62 696e 202f 4d79 5c30 3430 4e65 770d /bin /My\040New. 0500: 5c30 3132 466f 6c64 6572 2072 772c 6e6f \012Folder rw,no 0510: 6174 696d 6520 2d20 6578 7433 202f 6465 atime - ext3 /de 0520: 762f 646d 2d30 2072 772c 6461 7461 3d6f v/dm-0 rw,data=o 0530: 7264 6572 6564 0ardered. -- 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: mount points with whitespace are not escaped
On Mon, 3 Jun 2024, Jeremy Drake via Cygwin wrote: > /proc/self/mounts and /proc/self/mountinfo use octal escapes for ' ' and > \n (I was rather surprised they didn't escape \r also, but I guess they > don't have to because only ' ' and \n are used as delimiters): Went looking at Linux source code, I guess they escape ' ' \n and \, and "recently" added # (https://github.com/torvalds/linux/commit/ed5fce76b5ea40c87b44cafbe4f3222da8ec981a) -- 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
Request for support: some web pages on your site not responding
Hi! I've encountered difficulties accessing specific resources on your website cygwin.org as some pages fail to load. Would you mind providing me with the contact details of the responsible person to resolve this issue? Appreciate your assistance! -- 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: Request for support: some web pages on your site not responding
On 2024-06-03 21:14, Isabella Parker via Cygwin wrote:
I've encountered difficulties accessing specific resources on your website
cygwin.org as some pages fail to load. Would you mind providing me with the
contact details of the responsible person to resolve this issue?
Appreciate your assistance!
This mailing list is where available volunteers respond to help project users.
Please use cygwin.com in case of difficulties with cygwin.{org,net} - they were
registered to protect the name, and some issues may still occasionally occur at
the edge.
Please include precise details of your system and browser setup, and all issues
you encounter on cygwin.com.
Someone with relevant experience will respond to your issues, and if necessary,
ask the infrastructure team to deal with any problems.
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry
--
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
