DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E19963858C50
Date: Fri, 26 Jul 2024 12:56:44 -0700 (PDT)
To: cygwin@cygwin.com
cc: Johannes.Schindelin@gmx.de
Subject: Re: double-fork issue on Windows on ARM64
In-Reply-To: <0b48aa79-8579-882e-a40b-724267936788@jdrake.com>
Message-ID: <a3ec694e-e9d5-04db-fa21-b93b28f7a0d4@jdrake.com>
References: <78f294de-4c94-242a-722e-fd98e51edff9@jdrake.com>
 <23f23b0a-e60e-e3ff-4c1e-295599fdc813@jdrake.com>
 <0b48aa79-8579-882e-a40b-724267936788@jdrake.com>
MIME-Version: 1.0
Precedence: list
From: Jeremy Drake via Cygwin <cygwin@cygwin.com>
Reply-To: Jeremy Drake <cygwin@jdrake.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: cygwin-bounces~archive-cygwin=delorie.com@cygwin.com
Sender: "Cygwin" <cygwin-bounces~archive-cygwin=delorie.com@cygwin.com>

Replying to cygwin@cygwin.com list due to determination that this thread
was incorrectly sent to cygwin-developers.  I apologize for the
inconvenience.

On Tue, 21 May 2024, Jeremy Drake wrote:

> On Mon, 20 May 2024, Jeremy Drake wrote:
>
> > Today, I was attempting to look at the TerminateThread situation.  The
> > call in question comes from the attempt to terminate the wait_thread of a
> > chld_procs entry.  I noticed elsewhere in cygwin code (flock.cc) that
> > CancelSynchronousIo was being called, and that stood out to me because
> > chances are that the wait thread (if running) is going to be blocked in
> > ReadFile.  I am testing with the following hack, and so far have not seen
> > a hang
>
>
> I left my reproducer running with this hack, and I did eventually get an
> error exit from the intermediate subprocess, which seems to have been a
> signal 11 (if I'm reading the status from waitpid correctly).
>
> What I noticed today is that in pinfo.cc, near the end of proc_waiter, it
> sets vchild.wait_thread = NULL;.  If my reading of this is correct, that
> does nothing useful, because vchild is a stack variable there and the
> function returns soon after.  I that what that *intended* to do was to
> NULL out the wait_thread pointer that would be checked in proc_terminate,
> but there's no guarantee that the entry in chld_procs is in the same place
> at the end of proc_waiter as it was at the start (so arg may point to
> some other pinfo entirely).
>
> Does any of this make any sense, or am I barking up the wrong tree here?

I tried adding a new "procstuff" enum member and case to proc_subproc to
loop through all chld_procs and NULL out wait_threads that equal the
pointer passed in as "val"  This was called from the proc_waiter before
it NULLed out its local copy of vchild.  This did not help.

I am still fairly sure that somehow this terminate_thread call is where
the hang is happening, but I'm not seeing why.  This is definitely not
helped by the fact that debuggers cannot attach to the main thread for
some reason.

-- 
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