[Bug 34865] 64-bit mingw toolchain from Rtools fails to execute (cygwin 1.7.15-1, queued user APC not executed for signal handling)
wine-bugs at winehq.org
wine-bugs at winehq.org
Mon Nov 11 15:18:01 CST 2013
http://bugs.winehq.org/show_bug.cgi?id=34865
--- Comment #2 from Anastasius Focht <focht at gmx.net> 2013-11-11 15:18:01 CST ---
Hello again,
it seems the Cygwin dll distributed with R-studio is a custom build (snapshot)
that has a very short-lived patch applied which introduces the use of APC to
create the signal receiver thread.
Again: that patch never made it into official source tree!
After unsuccessfully digging the CVS history and I found a discussion related
to user APC on the Cygwin mailing list:
http://marc.info/?t=131176630600003
Patch: http://www.mail-archive.com/[email protected]/msg05242.html
--- quote ---
As sigproc_init is called during dll initialization, wait_sig thread is not
created as soon as possible.(this is known in msdn createthread reference.
http://msdn.microsoft.com/en-us/library/ms682453(v=vs.85).aspx) And then
wait_sig starts to wake up as sig_dispatch_pending enters waitforsingleobject.
then main thread stops for few ms. and it shows poor performance.
as a workaround, issue user apc call, let the os decide when to call them.
And the result was quite good. patch,changelog modified are attached.
Please review it.
--- quote ---
Corinna's answer:
--- quote ---
The slowdown of the code was the result of a patch which was supposed
to fix a potential race condition. Jojelino's patch looks nice, but
it might reintroduce a new race. Handle with care.
--- quote ---
Compare Cygwin1.dll disassembly (see patch source):
--- snip ---
610DA9E9 mov edx, 611EA590h ; "sync_proc_subproc"
...
610DAA04 mov dword ptr [eax+18h], 611EA5A2h ; "sig"
...
610DAA29 call GetCurrentThread
610DAA2E mov [esp+8], ebx
610DAA32 mov dword ptr [esp], 61003DB0h ; address of user APC
610DAA39 mov [esp+4], eax
610DAA3D call QueueUserAPC
...
--- snip ---
Date/size of cygwin dll:
--- snip ---
-rw-rw-r--. 1 focht focht 2288181 Jul 16 2012 cygwin1.dll
--- snip ---
--- quote ---
On Sat, Jul 30, 2011 at 05:09:08PM -0400, Christopher Faylor wrote:
Oops. Forgot to mention that these changes are available in the most
recent snapshot at: http://cygwin.com/snapshots/ .
--- quote ---
Unfortunately this snapshot is too far away and not available anymore.
The queued APC needs to be executed only once to create the real signal
receiver thread which handles the other end of the pipe.
My guess would be that this APC is implicitly triggered by some win API calls
that have alertable wait under the hood.
I manually triggered the APC and it indeed created the signal thread.
The APC entry point address 0x61003db0.
Direct win64 API calls from within the APC can be easily found at that range
0x61003xxx:
--- snip ---
...
002f:Call KERNEL32.QueueUserAPC(61003db0,fffffffe,61188380) ret=610daa42
002f:Ret KERNEL32.QueueUserAPC() retval=00000001 ret=610daa42
...
002f:Call
KERNEL32.CreateThread(6119a7ec,00000000,61003f30,61188380,00000000,61188384)
ret=61003d33
...
002f:Ret KERNEL32.CreateThread() retval=00000138 ret=61003d33
002f:Call KERNEL32.SetThreadPriority(00000138,00000002) ret=61003dd2
0030:Call PE DLL (proc=0x6107f390,module=0x61000000
L"cygwin1.dll",reason=THREAD_ATTACH,res=(nil))
002f:Ret KERNEL32.SetThreadPriority() retval=00000001 ret=61003dd2
0030:Ret PE DLL (proc=0x6107f390,module=0x61000000
L"cygwin1.dll",reason=THREAD_ATTACH,res=(nil)) retval=1
002f:Call KERNEL32.CloseHandle(00000138) ret=61003de0
0030:Call PE DLL (proc=0x7ecf6e94,module=0x7ec40000
L"user32.dll",reason=THREAD_ATTACH,res=(nil))
0030:Ret PE DLL (proc=0x7ecf6e94,module=0x7ec40000
L"user32.dll",reason=THREAD_ATTACH,res=(nil)) retval=1
...
0030:Starting thread proc 0x6107f360 (arg=0x61188380)
--- snip ---
I'm not sure why RStudio chose a Cygwin snapshot with custom patches applied
for their official 3.0.2 release for Windows.
Regards
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
More information about the wine-bugs
mailing list