public inbox for cygwin-patches@cygwin.com
 help / color / mirror / Atom feed
From: Jeremy Drake <cygwin@jdrake.com>
To: cygwin-patches@cygwin.com
Subject: Re: [PATCH] Cygwin: console: Avoid slipping past disable_master_thread check.
Date: Sat, 3 Feb 2024 10:48:02 -0800 (PST)	[thread overview]
Message-ID: <alpine.BSO.2.21.2402031042100.95909@resin.csoft.net> (raw)
In-Reply-To: <c8c3a5c3-72b7-7e1b-3ddf-d399090b49a1@gmx.de>

Thanks for taking the time to write this up, this issue has been bugging
me for years... (see also:
https://cygwin.com/pipermail/cygwin-patches/2021q4/011638.html)

On Sat, 3 Feb 2024, Johannes Schindelin wrote:

> Concretely, the hangs occur typically when some `pacman` process (a
> package manager using the MSYS2 runtime, i.e. the Cygwin runtime with
> several dozen patches on top) calls a few non-Cygwin processes. Those
> processes seem to succeed, but there is an extra `pacman` process left
> hanging around (reported using the same command-line as its parent
> process, indicating a `fork()`ed child process or maybe that
> signal-handler that is spawned for every non-Cygwin child process) and at
> that point the program hangs indefinitely (or at least until the GitHub
> workflow run times out after 6 hours).

I don't think this requires running non-Cygwin children - I see this most
often when pacman is using GPGME to validate signatueres.  That
fork/exec's (Cygwin) gpg.

> I was not able to obtain any helpful stacktraces, they all seem to make no
> sense, I only vaguely remember that one thread was waiting for an object,
> but that could be a false flag.

My recollection when I tried to debug was that every debugger I tried got
an error trying to get the context of the main thread of the hung process.
There was another thread, which seemed to be for Cygwin signal handling,
which was blithely waiting for an object, but I kind of expect that's what
it was supposed to be doing.

> Stopping those hanging `pacman` processes via `wmic process ... delete`
> counter-intuitively fails to result in `pacman` to exit with a non-zero
> exit code. Instead, the program now runs to completion successfully!

> Do you have any idea what the bug could be? Or how I could diagnose this
> better? Attaching via `gdb` only produces unhelpful stacktraces (that may
> even be bogus, by the looks of it). Or do you think that your patch that I
> am replying to could potentially fix this problem? How could the code be
> improved to avoid those hangs altogether, or at least to make them easier
> to diagnose?


      parent reply	other threads:[~2024-02-03 18:48 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-02 16:18 Takashi Yano
2024-02-03 14:53 ` Johannes Schindelin
2024-02-03 15:47   ` Takashi Yano
2024-02-03 18:48   ` Jeremy Drake [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.BSO.2.21.2402031042100.95909@resin.csoft.net \
    --to=cygwin@jdrake.com \
    --cc=cygwin-patches@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).