public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Qian Hong <fracting@gmail.com>
To: cygwin <cygwin@cygwin.com>
Subject: Re: [OT] Wine + Cygwin: `script -e` exit status forwarding randomly return zero for non zero child process
Date: Mon, 07 Sep 2015 11:03:00 -0000	[thread overview]
Message-ID: <CALd+sZRO9LbvQcQZ4PVf9Ge1e5Gu0kKTQkucm=YC68ENdkNNAA@mail.gmail.com> (raw)
In-Reply-To: <20150903105549.GT23669@calimero.vinschen.de>

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@cygwin.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

  reply	other threads:[~2015-09-07 11:03 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-02 14:28 Qian Hong
2015-09-02 17:04 ` Qian Hong
2015-09-03 10:55 ` Corinna Vinschen
2015-09-07 11:03   ` Qian Hong [this message]
2015-09-07 12:28     ` Corinna Vinschen
2015-09-07 17:14       ` Qian Hong
2015-09-08  8:30         ` Corinna Vinschen
2015-10-21  4:50           ` Qian Hong
2015-10-21  8:18             ` Corinna Vinschen

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='CALd+sZRO9LbvQcQZ4PVf9Ge1e5Gu0kKTQkucm=YC68ENdkNNAA@mail.gmail.com' \
    --to=fracting@gmail.com \
    --cc=cygwin@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).