[PATCH] Cygwin: pty: Not to change code page of parent console.
- The recent commit "Cygwin: pty: Fix timing of creating invisible console." breaks the feature added by commit 72770148, which prevents pty from changing code page of parent console. This patch restores that. --- winsup/cygwin/fhandler_console.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/winsup/cygwin/fhandler_console.cc b/winsup/cygwin/fhandler_console.cc index 5625b7be2..933614228 100644 --- a/winsup/cygwin/fhandler_console.cc +++ b/winsup/cygwin/fhandler_console.cc @@ -1610,7 +1610,7 @@ fhandler_console::close () if (con_ra.rabuf) free (con_ra.rabuf); - if (!have_execed) + if (!have_execed && !invisible_console) free_console (); return 0; } -- 2.36.0
[ANNOUNCEMENT] ascii 3.18-1{i686,x86_64} (TEST)
The following packages have been uploaded to the Cygwin distribution as test release: * ascii-3.18-1 The ascii utility provides easy conversion between various byte representations and the ASCII character table. It knows about a wide variety of hex, binary, octal, Teletype mnemonic, ISO/ECMA code point, slang names, XML entity names, and other representations. Given any one on the command line, it will try to display all others. Called with no arguments it displays a handy small ASCII chart. This package is the latest upstream version. After some testing period it will be moved from test to release. Any feedback is appreciated. Please send questions or concerns to the main Cygwin mailing list as usual. Libor -- *** 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.comcygwin.com If you need more information on unsubscribing, start reading here: https://sourceware.org/lists.html#unsubscribe -- 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
ascii 3.18-1{i686,x86_64} (TEST)
The following packages have been uploaded to the Cygwin distribution as test release: * ascii-3.18-1 The ascii utility provides easy conversion between various byte representations and the ASCII character table. It knows about a wide variety of hex, binary, octal, Teletype mnemonic, ISO/ECMA code point, slang names, XML entity names, and other representations. Given any one on the command line, it will try to display all others. Called with no arguments it displays a handy small ASCII chart. This package is the latest upstream version. After some testing period it will be moved from test to release. Any feedback is appreciated. Please send questions or concerns to the main Cygwin mailing list as usual. Libor -- *** 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.comcygwin.com If you need more information on unsubscribing, start reading here: https://sourceware.org/lists.html#unsubscribe
Re: [ITP] asr-manpages, funny-manpages
On 2022-05-08 09:15, Libor Ukropec wrote: Dne 07.05.2022 v 20:52 Brian Inglis napsal(a): I would like to offer to package the following projects for Cygwin. They have been extensively tested on my own system for decades. ;^> They are offered on the major distros listed below, and the cygport builds are available in my Google Drive folders. I haven't known them until now. Quite fun :) Built and installed without any issue. If I can give the GTG, here it is.. Thanks - now I just need another four or so. BTW, I noted LICENSE, CYGWIN_MAINTAINER, UPSTREAM_MAINTAINER variables ... are they used/shown somewhere and is it a best practise to have them in the cygport script? Something I think should be documented somewhere, are tracked in some other distros package trackers, easier to add on adoption, and useful when you want to submit bug reports upstream. Defining then as shell vars mean you can use them for searching or in commands. I recently audited my packages and there are still a dozen or so lacking that information that I will work on adding. -- 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.]
[PATCH] Cygwin: pty: Add missing attach_mutex guard.
--- winsup/cygwin/fhandler_tty.cc | 2 ++ 1 file changed, 2 insertions(+) diff --git a/winsup/cygwin/fhandler_tty.cc b/winsup/cygwin/fhandler_tty.cc index f6a7a6cf9..bb18d139e 100644 --- a/winsup/cygwin/fhandler_tty.cc +++ b/winsup/cygwin/fhandler_tty.cc @@ -3422,6 +3422,7 @@ skip_create: HeapFree (GetProcessHeap (), 0, hp); } + acquire_attach_mutex (mutex_timeout); if (get_ttyp ()->previous_code_page) SetConsoleCP (get_ttyp ()->previous_code_page); if (get_ttyp ()->previous_output_code_page) @@ -3452,6 +3453,7 @@ skip_create: mode |= DISABLE_NEWLINE_AUTO_RETURN; SetConsoleMode (hpConOut, mode); } + release_attach_mutex (); return true; -- 2.36.0
Re: Permissions issues after installing Windows 10
Greetings, Brent Epp! > I recently (finally) installed Windows 10 on my system (clean install). > All of my files are stored in on a secondary drive/partition, on which > cygwin is also installed. I expected to be able to just pick up where I > left off, but I'm getting all sorts of permissions issues with cygwin. I > did run the cygwin setup again to reinstall/upgrade. > First, I had restore my cygwin home directory from a backup, since it was > giving me permissions errors on .bash_history, .ssh, etc, but the biggest > headache is with git repos. First, it gives a "fatal: unsafe repository" > error. If I add it to the safe directories list, it git still has to > reindex the repo every time I run `git status`, and it still fails when I try > to enter a commit. > It seems most or everything is owned by "Administrators". The only way > I've been able to fix this is to go through the Windows advanced permissions > dialog, change the owner to my user, and set all sub-objects to inheritable > permissions, but I'm very leery about mass changes like this. > Why did this happen? And is there a better/safer/correct way to fix this? The only way is to install a clean copy of Cygwin and carefully copy your changes over. This will ensure that all permissions are set correctly, and all programs are rebased correctly as well. This is because Windows uses a very different file access control that that of simple POSIX permissions, on top of which Cygwin emulates them. If you want your pain to be somewhat less in the future, move your home away from Cygwin directory and use noacl flag on it, which will defer permissions control to the underlying OS layer. I'm using my Windows profile as Cygwin home, but your mileage may vary. -- With best regards, Andrey Repin Sunday, May 8, 2022 18:32:07 Sorry for my terrible english... -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[PATCH] Cygwin: pty: Avoid deadlock when pcon is started on console.
- Previously, "env SHELL=cmd script" command in console caused
deadlock when starting cmd.exe. This patch fixes the issue.
---
winsup/cygwin/fhandler_tty.cc | 34 +-
winsup/cygwin/select.cc | 2 --
2 files changed, 17 insertions(+), 19 deletions(-)
diff --git a/winsup/cygwin/fhandler_tty.cc b/winsup/cygwin/fhandler_tty.cc
index 9ab681d6c..f6a7a6cf9 100644
--- a/winsup/cygwin/fhandler_tty.cc
+++ b/winsup/cygwin/fhandler_tty.cc
@@ -1171,11 +1171,7 @@ fhandler_pty_slave::reset_switch_to_nat_pipe (void)
bool need_restore_handles = get_ttyp ()->pcon_activated;
WaitForSingleObject (pipe_sw_mutex, INFINITE);
if (get_ttyp ()->pcon_activated)
- {
- acquire_attach_mutex (mutex_timeout);
- close_pseudoconsole (get_ttyp ());
- release_attach_mutex ();
- }
+ close_pseudoconsole (get_ttyp ());
else
hand_over_only (get_ttyp ());
ReleaseMutex (pipe_sw_mutex);
@@ -3244,9 +3240,11 @@ fhandler_pty_slave::setup_pseudoconsole ()
GetCurrentProcess (), ,
0, TRUE, DUPLICATE_SAME_ACCESS);
CloseHandle (pcon_owner);
+ acquire_attach_mutex (mutex_timeout);
FreeConsole ();
AttachConsole (get_ttyp ()->nat_pipe_owner_pid);
init_console_handler (false);
+ release_attach_mutex ();
goto skip_create;
}
@@ -3368,9 +3366,11 @@ fhandler_pty_slave::setup_pseudoconsole ()
HeapFree (GetProcessHeap (), 0, si.lpAttributeList);
/* Attach to pseudo console */
+ acquire_attach_mutex (mutex_timeout);
FreeConsole ();
AttachConsole (pi.dwProcessId);
init_console_handler (false);
+ release_attach_mutex ();
/* Terminate helper process */
SetEvent (goodbye);
@@ -3535,8 +3535,10 @@ void
fhandler_pty_slave::close_pseudoconsole (tty *ttyp, DWORD force_switch_to)
{
DWORD switch_to = get_winpid_to_hand_over (ttyp, force_switch_to);
+ acquire_attach_mutex (mutex_timeout);
ttyp->previous_code_page = GetConsoleCP ();
ttyp->previous_output_code_page = GetConsoleOutputCP ();
+ release_attach_mutex ();
if (nat_pipe_owner_self (ttyp->nat_pipe_owner_pid))
{ /* I am owner of the nat pipe. */
if (switch_to)
@@ -3578,19 +3580,23 @@ fhandler_pty_slave::close_pseudoconsole (tty *ttyp,
DWORD force_switch_to)
ttyp->h_pcon_conhost_process = new_conhost_process;
ttyp->h_pcon_in = new_pcon_in;
ttyp->h_pcon_out = new_pcon_out;
+ acquire_attach_mutex (mutex_timeout);
FreeConsole ();
pinfo p (myself->ppid);
if (!p || !AttachConsole (p->dwProcessId))
AttachConsole (ATTACH_PARENT_PROCESS);
init_console_handler (false);
+ release_attach_mutex ();
}
else
{ /* Close pseudo console and abandon the ownership of the nat pipe. */
+ acquire_attach_mutex (mutex_timeout);
FreeConsole ();
pinfo p (myself->ppid);
if (!p || !AttachConsole (p->dwProcessId))
AttachConsole (ATTACH_PARENT_PROCESS);
init_console_handler (false);
+ release_attach_mutex ();
/* Reconstruct pseudo console handler container here for close */
HPCON_INTERNAL *hp =
(HPCON_INTERNAL *) HeapAlloc (GetProcessHeap (), 0,
@@ -3610,11 +3616,13 @@ fhandler_pty_slave::close_pseudoconsole (tty *ttyp,
DWORD force_switch_to)
}
else
{ /* Just detach from the pseudo console if I am not owner. */
+ acquire_attach_mutex (mutex_timeout);
FreeConsole ();
pinfo p (myself->ppid);
if (!p || !AttachConsole (p->dwProcessId))
AttachConsole (ATTACH_PARENT_PROCESS);
init_console_handler (false);
+ release_attach_mutex ();
}
}
@@ -4040,11 +4048,7 @@ fhandler_pty_slave::setup_for_non_cygwin_app (bool
nopcon, PWCHAR envblock,
}
bool pcon_enabled = false;
if (!nopcon)
-{
- acquire_attach_mutex (mutex_timeout);
- pcon_enabled = setup_pseudoconsole ();
- release_attach_mutex ();
-}
+pcon_enabled = setup_pseudoconsole ();
ReleaseMutex (pipe_sw_mutex);
/* For pcon enabled case, transfer_input() is called in master::write() */
if (!pcon_enabled && get_ttyp ()->getpgid () == myself->pgid
@@ -4077,11 +4081,7 @@ fhandler_pty_slave::cleanup_for_non_cygwin_app
(handle_set_t *p, tty *ttyp,
}
WaitForSingleObject (p->pipe_sw_mutex, INFINITE);
if (ttyp->pcon_activated)
-{
- acquire_attach_mutex (mutex_timeout);
- close_pseudoconsole (ttyp, force_switch_to);
- release_attach_mutex ();
-}
+close_pseudoconsole (ttyp, force_switch_to);
else
hand_over_only (ttyp, force_switch_to);
ReleaseMutex (p->pipe_sw_mutex);
@@ -4111,6 +4111,7 @@ fhandler_pty_slave::setpgid_aux (pid_t pid)
bool
Re: python-future missing python 3.8 and 3.9 support
Dne 08.05.2022 v 14:43 Jon Turney napsal(a): On 05/05/2022 00:04, Libor Ukropec wrote: Dne 04.05.2022 v 0:15 Jon Turney napsal(a): On 03/05/2022 21:25, Libor Ukropec wrote: Hello Jon, maintainers, who is now the maintainer of the python-future - Jon Turney? Yes, it seems to be me, I don't know quite why though... Hello Jon, in this case if you want to, I can take over the responsibility for this package, just let me know. Thanks. I've given you maintainership of python-future, although it seems pretty mature, so hopefully won't require updating. I am a cygwin user for ages and I'll be glad if I am able to give something back to this community. The python-future supports only python 2.7, 3.6 and 3.7 and these are basically obsolete. I'd like to add support for 3.8 and 3.9 - it should allow me to support `duplicity` package with the latest python (3.9). PYTHON_WHEEL_VERSIONS variable should help. Can I kindly ask someone >>... Thanks. I rebuilt python-future with this change. That was quick, thank you. Unfortunately because of the dependency hell (python paramiko => nacl, and may be others) I cannot use the Python 3.9, still your work enables me to use at least the Python 3.8 (where all dependencies are resolved), which is great! Yeah, the situation is not ideal, and ideally something would be done to improve this situation, perhaps so we can automatically rebuild all the python packages for 3.9 or 3.10 when we get to that, but ... SHTDI... Well, if this can be automated that will be cool. If not, I'm ready to help.
Re: [ITP] asr-manpages, funny-manpages
Dne 07.05.2022 v 20:52 Brian Inglis napsal(a): I would like to offer to package the following projects for Cygwin. They have been extensively tested on my own system for decades. ;^> They are offered on the major distros listed below, and the cygport builds are available in my Google Drive folders. I haven't known them until now. Quite fun :) Built and installed without any issue. If I can give the GTG, here it is.. BTW, I noted LICENSE, CYGWIN_MAINTAINER, UPSTREAM_MAINTAINER variables ... are they used/shown somewhere and is it a best practise to have them in the cygport script? Regards, Libor asr-manpages 2406 alt.sysadmin.recovery manual pages A set of humorous manual pages developed on alt.sysadmin.recovery (don't treat them seriously!). Some may be considered non-PC, NSFW, or offensive. The authors recommend these man pages be installed on every system. Home http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/misc/asr-manpages Arch https://aur.archlinux.org/packages/asr-manpages DragonFly https://github.com/DragonFlyBSD/DPorts/tree/master/misc/asr-manpages FreeBSD https://www.freshports.org/misc/asr-manpages NetBSD http://pkgsrc.se/misc/asr-manpages Gentoo https://packages.gentoo.org/packages/games-misc/asr-manpages Slack https://slackbuilds.org/repository/15.0/misc/asr-manpages/ Ubuntu https://launchpad.net/ubuntu/+source/asr-manpages Repology https://repology.org/project/asr-manpages https://drive.google.com/drive/folders/1b8DTVX_aiaZk90Lwd21W1kJ5NGOs73HX funny-manpages 2.3 humorous manual pages A set of miscellaneous humorous manual pages (don't treat them seriously!). Some may be considered non-PC, NSFW, or offensive. You've been warned. Home https://github.com/ltworf/funny-manpages Arch https://aur.archlinux.org/packages/funny-manpages Debian https://packages.debian.org/sid/source/funny-manpages Gentoo https://packages.gentoo.org/packages/games-misc/funny-manpages OpenSuSE http://packman.links2linux.org/package/funny-manpages Slack https://slackbuilds.org/repository/15.0/misc/funny-manpages/ Ubuntu https://launchpad.net/ubuntu/+source/funny-manpages Repology https://repology.org/project/funny-manpages https://drive.google.com/drive/folders/1n_P6qCF7LiOqMKsDpFz9qZsdvT4-BXd8
[PATCH] Cygwin: pty: Change the condition to send Ctrl-C event.
- Previously, non-cygwin app started by "script -c "
receives Ctrl-C twice. This patch fixes the issue.
---
winsup/cygwin/fhandler_termios.cc | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/winsup/cygwin/fhandler_termios.cc
b/winsup/cygwin/fhandler_termios.cc
index 4eff5eab3..735423bf2 100644
--- a/winsup/cygwin/fhandler_termios.cc
+++ b/winsup/cygwin/fhandler_termios.cc
@@ -324,9 +324,6 @@ fhandler_termios::process_sigs (char c, tty* ttyp,
fhandler_termios *fh)
pid_t pgid = ttyp->pgid;
/* The name *_nat stands for 'native' which means non-cygwin apps. */
- pinfo leader (pgid);
- bool cyg_leader = /* The process leader is a cygwin process. */
-leader && !(leader->process_state & PID_NOTCYGWIN);
bool ctrl_c_event_sent = false;
bool need_discard_input = false;
bool pg_with_nat = false; /* The process group has non-cygwin processes. */
@@ -373,9 +370,9 @@ fhandler_termios::process_sigs (char c, tty* ttyp,
fhandler_termios *fh)
instead. */
if (p->process_state & PID_NEW_PG)
GenerateConsoleCtrlEvent (CTRL_BREAK_EVENT, p->dwProcessId);
- else if ((!fh || fh->need_send_ctrl_c_event () || cyg_leader)
- && !ctrl_c_event_sent) /* cyg_leader is needed by GDB
-with non-cygwin inferior */
+ else if ((!fh || fh->need_send_ctrl_c_event ()
+ || p->exec_dwProcessId == p->dwProcessId)
+ && !ctrl_c_event_sent)
{
GenerateConsoleCtrlEvent (CTRL_C_EVENT, 0);
ctrl_c_event_sent = true;
--
2.36.0
Re: python-future missing python 3.8 and 3.9 support
On 05/05/2022 00:04, Libor Ukropec wrote: Dne 04.05.2022 v 0:15 Jon Turney napsal(a): On 03/05/2022 21:25, Libor Ukropec wrote: Hello Jon, maintainers, who is now the maintainer of the python-future - Jon Turney? Yes, it seems to be me, I don't know quite why though... Hello Jon, in this case if you want to, I can take over the responsibility for this package, just let me know. Thanks. I've given you maintainership of python-future, although it seems pretty mature, so hopefully won't require updating. The python-future supports only python 2.7, 3.6 and 3.7 and these are basically obsolete. I'd like to add support for 3.8 and 3.9 - it should allow me to support `duplicity` package with the latest python (3.9). PYTHON_WHEEL_VERSIONS variable should help. Can I kindly ask someone >>... Thanks. I rebuilt python-future with this change. That was quick, thank you. Unfortunately because of the dependency hell (python paramiko => nacl, and may be others) I cannot use the Python 3.9, still your work enables me to use at least the Python 3.8 (where all dependencies are resolved), which is great! Yeah, the situation is not ideal, and ideally something would be done to improve this situation, perhaps so we can automatically rebuild all the python packages for 3.9 or 3.10 when we get to that, but ... SHTDI...
Re: [ITA] ascii
On 07/05/2022 20:38, Libor Ukropec wrote: I'd like to offer to adopt maintenance of ascii (ASCII character tables) updated to from 3.15 (2015) to 3.18 (2017) Updated cygport: https://github.com/cz6ace/cygwin-ascii I've added you as the maintainer for ascii. Thanks.
Re: mintty crashes on Windows 7
On Sun, May 8, 2022 at 2:09 PM Takashi Yano wrote: > I have pushed two patches to cygwin-3_3-branch. I am not sure > why, but the issue (bash with readline crash) seems to disappear. > > Could you please try? It no longer crashes with these fixes. Thanks! - Orgad -- 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: mintty crashes on Windows 7
On Sat, 7 May 2022 09:20:51 +0900
Takashi Yano wrote:
> On Sat, 7 May 2022 05:13:23 +0900
> Takashi Yano wrote:
> > On Fri, 6 May 2022 21:16:10 +0200 (CEST)
> > Johannes Schindelin wrote:
> > > Takashi, for the record, I find it hard to believe that the bug is
> > > libreadline's because Orgad's scenario works if he reverts that patch in
> > > the _MSYS2 runtime_, _and_ it is rather dubious that libreadline would
> > > potentially do anything that makes a call to `GetProcessWindowStation()`
> > > not fail but _crash_.
> >
> > I found the following test case also crashes with that commit.
> >
> > 1) Compile rl_stc.c with gcc rl_stc.c -lreadline -o rl_stc.c
> > 2) mintty --hold always ./rl_stc
> >
> > /* rl_stc.c */
> > #include
> > #include
> > #include
> >
> > int main(int argc, char *argv[])
> > {
> > char *str;
> > if (argc > 1) {
> > str = readline(">> ");
> > printf("%s\n", str);
> > free(str);
> > }
> > return 0;
> > }
> >
> > In this test case, no args is specified, so readline() is
> > not called. However, this crashes indeed. This means just
> > loading msys-readline8.dll causes the crash.
>
> 1') gcc --static rl_stc.c -lreadline -lncurses -o rl_stc.c
> 2) mintty --hold always ./rl_stc
>
> also causes crash. In this case, no code from libreadline is
> executed, I think. Why this triggers GetProcessWindowStation()
> crash?
I have pushed two patches to cygwin-3_3-branch. I am not sure
why, but the issue (bash with readline crash) seems to disappear.
Could you please try?
--
Takashi Yano
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[PATCH] Cygwin: pty: Fix timing of creating invisible console.
- Previously, invisible console was created in fixup_after_exec().
However, actually this should be done in fixup_after_fork(). this
patch fixes the issue.
---
winsup/cygwin/fhandler_tty.cc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/winsup/cygwin/fhandler_tty.cc b/winsup/cygwin/fhandler_tty.cc
index bdde1dce6..9ab681d6c 100644
--- a/winsup/cygwin/fhandler_tty.cc
+++ b/winsup/cygwin/fhandler_tty.cc
@@ -2467,6 +2467,8 @@ fhandler_pty_slave::bg_check (int sig, bool dontsignal)
void
fhandler_pty_slave::fixup_after_fork (HANDLE parent)
{
+ create_invisible_console ();
+
// fork_fixup (parent, inuse, "inuse");
// fhandler_pty_common::fixup_after_fork (parent);
report_tty_counts (this, "inherited", "");
@@ -2475,8 +2477,6 @@ fhandler_pty_slave::fixup_after_fork (HANDLE parent)
void
fhandler_pty_slave::fixup_after_exec ()
{
- create_invisible_console ();
-
if (!close_on_exec ())
fixup_after_fork (NULL); /* No parent handle required. */
--
2.36.0
[PATCH] Cygwin: pty: Fix acquiring attach_mutex timing.
- When temporarily attaching a console, the timing of acquiring
attach_mutex was not appropriate. This sometimes caused master
forwarding thread to crash on Ctrl-C in Windows 7. This patch
fixes the issue.
---
winsup/cygwin/fhandler_tty.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/winsup/cygwin/fhandler_tty.cc b/winsup/cygwin/fhandler_tty.cc
index 484bf55dc..bdde1dce6 100644
--- a/winsup/cygwin/fhandler_tty.cc
+++ b/winsup/cygwin/fhandler_tty.cc
@@ -4171,13 +4171,13 @@ DWORD
fhandler_pty_common::attach_console_temporarily (DWORD target_pid)
{
DWORD resume_pid = 0;
+ acquire_attach_mutex (mutex_timeout);
pinfo pinfo_resume (myself->ppid);
if (pinfo_resume)
resume_pid = pinfo_resume->dwProcessId;
if (!resume_pid)
resume_pid = get_console_process_id (myself->dwProcessId, false);
bool console_exists = fhandler_console::exists ();
- acquire_attach_mutex (mutex_timeout);
if (!console_exists || resume_pid)
{
FreeConsole ();
--
2.36.0
Re: load average calculation failing
On 08/05/2022 08:01, Mark Geisert wrote: Mark Geisert wrote (on the main Cygwin mailing list): I've recently noticed that the 'xload' I routinely run shows zero load even with compute-bound processes running. This is on both Cygwin pre-3.4.0 as well as 3.3.4. A test program, shown below, indicates that getloadavg() is returning with 0 status, i.e. not an error but no elems of the passed-in array updated. Stepping with gdb through the test program seems weird within the loadavginfo::load_init method. Single-stepping at line loadavg.cc:68 goes to strace.h:52 and then to _sigbe ?! I had recently updated both Cygwin and Windows 10 to latest at the same time so I cannot say when the failure started. Last day or two at most. [...] I've debugged a bit further.. Within Cygwin's loadavg.cc:load_init(), the PdhOpenQueryW() call returns successfully. The subsequent PdhAddEnglishCounterW() call is unsuccessful. It returns status 0x87D0 == PDH_CSTATUS_NO_MACHINE. The code (at line 68 mentioned above) calls debug_printf() to conditionally display the error, which is what leads to the strace.h and _sigbe; that's fine. The weird PDH_CSTATUS_NO_MACHINE is the problem. I'll try running the example from an elevated shell. Or rebooting the machine. After that it's consulting some oracle TBD. :-( Thanks for looking into this. You can find the user space version of this code I initially wrote at https://github.com/jon-turney/windows-loadavg, which might save you some time. I can't reproduce this on W10 21H1, so I think this must be due to some change in later Windows...
