X-Recipient:	archive-cygwin AT delorie DOT com
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=
	UJk7X/FCZdpjJmRjrJ6ChbqT5SkZjgZZSHP96XrgJemDKijQLJLzAHOdBIEaHqoc
	jSC/XgbV7c1DguV5o6Z6yYBs+MkvKqbVv9b45iCPvealoHhmGD38rGD2S3ZerHJW
	+AZCJstjMt2kt0V/8WUaxWTKeT5GiWru2Cxt+ZQOXjE=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; 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; s=default; bh=fpp
	0oa7ZjI23cn5m8eRcq6XwaaQ=; b=yDgbXjVYbbEJvzVc/8GzLrlI4e9b6u8k/M/
	bXPrTQ449MqMrTzGOr+ZhZ47yEuX6wuhbf8vC/ifJMptrYpVz0lltevlG+RITs6j
	tpRRYtuvnCvRU8+pFNk/6u0Ye+YpR1iwVGaC3rNiRWPCoHSIf9REsqOUP6pULcZi
	pPcC6JHM=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=0.5 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2
X-HELO:	mail-wi0-f174.google.com
X-Received:	by 10.180.10.170 with SMTP id j10mr4642214wib.77.1441213474303; Wed, 02 Sep 2015 10:04:34 -0700 (PDT)
MIME-Version:	1.0
Reply-To:	fracting AT gmail DOT com
In-Reply-To:	<CALd+sZS6eHn8tUxCzB-JhGkfn2FUzg5dNKHwcY+ryBT-o=2DFw@mail.gmail.com>
References:	<CALd+sZS6eHn8tUxCzB-JhGkfn2FUzg5dNKHwcY+ryBT-o=2DFw AT mail DOT gmail DOT com>
From:	Qian Hong <fracting AT gmail DOT com>
Date:	Thu, 3 Sep 2015 01:03:54 +0800
Message-ID:	<CALd+sZQnGrfUwW0c9PufVkwhK=kxuNkXCVzg=i3myydMv_aeqA@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>
X-IsSubscribed:	yes

Dear folks, here is a few update:

This bug was originally found with MSYS2, but I've confirm it happens
on Cygwin (CYGWIN_NT-5.1  2.2.1(0.289/5/3) 2015-08-20 11:40 i686
Cygwin) as well.
For convenient of compile&test I'm mostly debugging on MSYS2, which is
rebased above the below Cygwin commit:

commit 7f3efa3b65e50b35d4e9f895e625e0878edc196a
Author: Corinna Vinschen
Date:   Tue Aug 25 22:23:01 2015 +0200
winsup.h: Claim Windows 10 support

In theory the testing result should be similar enough to recent
Cygwin. Forgive me for not compiling Cygwin, I can do that again if
anyone ask.

Here is some update of debugging information:

I added a breakpoint in pinfo::maybe_set_exit_code_from_windows, and
started `script -e -c "exit 5"`, with my customer compiled script.exe
from util-linux.

script.exe hits the breakpoints twice in every debugging session. The
following statements are for the first hit point since I found
different status in the first hit point for different script.exe exit
status.

From my test, whenever script.exe forwards the exit status correctly
(returns 5), oexitcode in pinfo::maybe_set_exit_code_from_windows is
set to 0x8000500; whenever script.exe forwards the exit status wrongly
(returns 0), oexitcode in pinfo::maybe_set_exit_code_from_windows is
set to 0x0.

Here is some debugging log

(gdb) r
Starting program:
/scripts2/util-linux/src/build-i686-pc-msys/script.exe -e -c "exit 5"
[New Thread 253.0x106]
[New Thread 253.0xb7]
[New Thread 253.0x88]
Script started, file is typescript
Script done, file is typescript
[Switching to Thread 253.0x88]

Breakpoint 1, pinfo::maybe_set_exit_code_from_windows()@4 (this=0xa0b70c)
    at /scripts2/msys2-runtime/src/msys2-runtime/winsup/cygwin/pinfo.cc:183
183       DWORD x = 0xdeadbeef;
(gdb) n
184       DWORD oexitcode = self->exitcode;
(gdb)
186       if (hProcess && !(self->exitcode & EXITCODE_SET))
(gdb) p/x oexitcode
$3 = 0x0
(gdb) bt
#0  pinfo::maybe_set_exit_code_from_windows()@4 (this=0xa0b70c)
    at /scripts2/msys2-runtime/src/msys2-runtime/winsup/cygwin/pinfo.cc:186
#1  0x610c51b1 in proc_waiter (arg=0x611cae80 <cprocs>)
    at /scripts2/msys2-runtime/src/msys2-runtime/winsup/cygwin/pinfo.cc:1042
#2  0x61004955 in cygthread::callfunc(bool)@8 (this=0x611b97f0 <threads+48>,
    issimplestub=false)
    at /scripts2/msys2-runtime/src/msys2-runtime/winsup/cygwin/cygthread.cc:51
#3  0x61004ae0 in cygthread::stub(void*)@4 (arg=0x611b97f0 <threads+48>)
    at /scripts2/msys2-runtime/src/msys2-runtime/winsup/cygwin/cygthread.cc:93
#4  0x610058bd in _cygtls::call2(unsigned long (*)(void*, void*),
void*, void*)@16 (this=0xa0ce64, func=0x6100495a
<cygthread::stub(void*)@4>,
    arg=0x611b97f0 <threads+48>, buf=0xa0b818)
    at /scripts2/msys2-runtime/src/msys2-runtime/winsup/cygwin/cygtls.cc:111
#5  0x61005726 in _cygtls::call (func=0x6100495a <cygthread::stub(void*)@4>,
    arg=0x611b97f0 <threads+48>)
    at /scripts2/msys2-runtime/src/msys2-runtime/winsup/cygwin/cygtls.cc:30
#6  0x6108d5e2 in threadfunc_fe (arg=0x611b97f0 <threads+48>)
    at /scripts2/msys2-runtime/src/msys2-runtime/winsup/cygwin/init.cc:32
#7  0x7bc83d80 in ?? ()
#8  0x7bc86e2f in ?? ()
#9  0x7bc83d5e in ?? ()
#10 0x7bc8e01f in ?? ()
#11 0xb7561f16 in ?? ()
---Type <return> to continue, or q <return> to quit---

Regarding the functions in 0x7bc83d80:
No symbols here because of limitation of using gdb for windows on top
of Wine. this module is Wine's ntdll.dll. the address is
call_thread_func_wrapper+0xc in dlls/ntdll/sigail_i386.c, which is
part of normal way to start a thread in Wine.

Source code: https://github.com/wine-compholio/wine-patched/blob/b4b0eb9f02aef47a0efaae0439aad30d1face1bf/dlls/ntdll/signal_i386.c#L2992
Wine-dbg>disas 0x7bc83d74
0x7bc83d74 call_thread_func_wrapper in ntdll: pushl %ebp
0x7bc83d75 call_thread_func_wrapper+0x1 in ntdll: movl %esp,%ebp
0x7bc83d77 call_thread_func_wrapper+0x3 in ntdll: subl $4,%esp
0x7bc83d7a call_thread_func_wrapper+0x6 in ntdll: pushl 0xc(%ebp)
0x7bc83d7d call_thread_func_wrapper+0x9 in ntdll: call *0x8(%ebp)
0x7bc83d80 call_thread_func_wrapper+0xc in ntdll: leal 0xfffffffc(%ebp),%esp
0x7bc83d83 call_thread_func_wrapper+0xf in ntdll: pushl %eax
0x7bc83d84 call_thread_func_wrapper+0x10 in ntdll: call 0x7bc8eb00
exit_thread [/media/workspace/src/wine-staging-local/dlls/ntdll/thread.c:386]
in ntdll
0x7bc83d89 call_thread_func_wrapper+0x15 in ntdll: int $3
0x7bc83d8a call_thread_func_wrapper+0x16 in ntdll: nop


Anyone could provide some hints where did the variable self->exitcode
came from? I need to understand why it was 0x0 sometimes and was
0x8000500 the other times.

Thanks very much!

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

- Raw text -