DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:reply-to:in-reply-to:references
	:from:date:message-id:subject:to:content-type; q=dns; s=default; b=
	gG4zlg2I+5wJ2BwO9Q5hrw+AMcHDZI5T4mldjU9H0rItFzAiC9s0V4x1OPgeMVrP
	FT8xQZod6x4JM7pWputdA7cI9rM6B7wOjMB/VhVEs4nVN0Cm/44pNwDL/g7IAtz2
	0/iY5xEhtFadboP8PHExyC5DC8NCUzY6YWDzCveXHQg=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
MIME-Version: 1.0
Reply-To: fracting AT gmail DOT com
In-Reply-To: <20150903105549.GT23669@calimero.vinschen.de>
References: <CALd+sZS6eHn8tUxCzB-JhGkfn2FUzg5dNKHwcY+ryBT-o=2DFw AT mail DOT gmail DOT com> <20150903105549 DOT GT23669 AT calimero DOT vinschen DOT de>
From: Qian Hong <fracting AT gmail DOT com>
Date: Mon, 7 Sep 2015 19:02:15 +0800
Message-ID: <CALd+sZRO9LbvQcQZ4PVf9Ge1e5Gu0kKTQkucm=YC68ENdkNNAA@mail.gmail.com>
Subject: Re: [OT] Wine + Cygwin: `script -e` exit status forwarding randomly return zero for non zero child process
To: cygwin <cygwin AT cygwin DOT com>
Content-Type: text/plain; charset=UTF-8

Hi Corinna,

Sorry for delay, our progress on this issue is slow.

Many thanks for your great information, it does help us became closer
to the reason.

On Thu, Sep 3, 2015 at 6:55 PM, Corinna Vinschen
<corinna-cygwin AT cygwin DOT com> wrote:
> Comparing the straces, two interesting facts are conspicuous:
> - After the forked script returned, what happens in the parent is absolutly
>   identical in both cases, up to a point during exit.  This point is reached
>   with line 1573 in the "bad" case and line 1580 in the "good" case.  Then
>   "something" happens:
>

Thanks for the analysis, this does help us realized it should be a
very low level issue, in a level I wasn't doubt about.

>   In the bad case the pty master thread gets an error condition returned
>   from DisconnectNamedPipe:
>
>     305 2754169 [ptym] script 25 fhandler_pty_master::pty_master_thread:
>     DisconnectNamedPipe, Win32 error 6
>
Good catch. I tested again and again, and I found the
DisconnectNamedPipe error doesn't happen in every bad log, so it is
not related to this issue, but it is interesting, it certainly
indicates something else is wrong, which is on my todo list.


>    To me this looks like the "bad" script has been exited forcefully
>    for some reason.
>

Yeah, this is the hard part. Sebastian has some progress on it, I
quote his note here:

=== quote ===

Cygwin tries to forcibly kill a thread, the implementation for that is
available here:
https://github.com/Alexpux/Cygwin/blob/79511853f788111efd975651f87eabbd4a8cbf6d/winsup/cygwin/cygthread.cc#L296

Excerpt from the log with annotations:

--- snip ---
0027:Call KERNEL32.TerminateThread(00000168,00000000) ret=610055ca
0027: terminate_thread( handle=0168, exit_code=0 )
0027: terminate_thread() = 0 { self=0, last=0 }
0027:Ret  KERNEL32.TerminateThread() retval=00000001 ret=610055ca
// handle 00000168 corresponds to thread 0x0029

0027:Call KERNEL32.WaitForSingleObject(00000168,ffffffff) ret=610055e0
0027: select( flags=2, cookie=0060ba6c, timeout=infinite,
prev_apc=0000, result={}, data={WAIT,handles={0168}} )
0027: select() = 0 { timeout=infinite, call={APC_NONE}, apc_handle=0000 }
0027:Ret  KERNEL32.WaitForSingleObject() retval=00000000 ret=610055e0
// WaitForSingleObject doesn't block, so cygwin assumes the thread is gone

[...]

0027:Call KERNEL32.VirtualFree(00a10000,00000000,00008000) ret=61005767
// Cygwin tries to release the thread stack

0029:Ret  KERNEL32.SetEvent() retval=00000001 ret=61005415
0029:Call KERNEL32.WaitForSingleObject(00000170,ffffffff) ret=6100543a
0029: select( flags=2, cookie=00a0b42c, timeout=infinite,
prev_apc=0000, result={}, data={WAIT,handles={0170}} )
0029: select() = PENDING { timeout=infinite, call={APC_NONE}, apc_handle=0000 }
// Crash. There is no core dump, so probably it crashed somewhere
inside of the pthread implementation.

0027: *killed* exit_code=0
0027: *sent signal* signal=3
0028: *killed* exit_code=0
0029: *killed* exit_code=0
002e: *killed* exit_code=0
0026: *process killed*
--- snip ---


As a workaround NtFreeVirtualMemory can be replaced with a no-op
implementation returning STATUS_SUCCESS.
=== quote ===

> There's something else which occured to me while looking through both
> straces:  Are you aware that Windows PIDs are *always* multiples of 4?
>
>   PID 0, 4, 8, 12, 16, ...  exist
>   PID 1, 2, 3, 5, 6, 7, ... don't.
>
> Wine apparently doesn't follow this scheme.  I would treat that as a bug.
> I can easily imagine applications which rely on the fact that PIDs are
> always multiples of four and use the lower two bits for dubious purposes.
> I'd suggest to change that in Wine for compatibility reasons.

Good catch, I didn't noticed about the number magic, many thanks. Will
add this one to my todo list as well.

It would takes some more time until we complete fix this bug, we'll
update again once we finish it.

Thank you again for your great help and enjoy your vocation!
(Off-topic: vocation at Oktoberfest? :D http://www.oktoberfest.de/en/
)


-- 
Regards,
Qian Hong

-
http://www.winehq.org

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple