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=
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: <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>
Content-Type: text/plain; charset=UTF-8

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