X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-3.5 required=5.0 	tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS,WEIRD_PORT
X-Spam-Check-By: sourceware.org
Message-ID: <4AD8220D.8000908@cwilson.fastmail.fm>
Date: Fri, 16 Oct 2009 03:34:37 -0400
From: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: fork failure?
References: <4AD732C7 DOT 4020301 AT cwilson DOT fastmail DOT fm> <4AD73B83 DOT 9060505 AT gmail DOT com> <4AD74586 DOT 8070803 AT cwilson DOT fastmail DOT fm> <4AD752C8 DOT 2040908 AT gmail DOT com> <4AD7B135 DOT 6020401 AT cwilson DOT fastmail DOT fm>
In-Reply-To: <4AD7B135.6020401@cwilson.fastmail.fm>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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

Charles Wilson wrote:
> Dave Korn wrote:
>> Charles Wilson wrote:
>>> I'm not familiar at all with procmon (sysinternals, right?) but I'll
>>> look into it.
>>   Yep, it's dead useful for making sure that stuff at least starts up, and you
>> can often get a clue how far the code has got by seeing what handles it's
>> opened and syscalls its made.
> 
> Well, it appears that the child is dying in dcrt0.c dll_crt0_1() when it
> calls cygheap->cwd.init().  

Apparently not.

It seems that there is a large time gap between the NT syscalls
displayed by procmon:

43673	6:58:17.3634216 PM gpg-agent.exe   568  CreateFile
43674	6:58:17.3634756 PM gpg-agent.exe   568  CloseFile
          <<< large gap here, where the actual error   >>>
          <<< occurs, prior to signal being handled... >>>
53626	6:58:19.0002272 PM gpg-agent.exe   568  Thread Exit <<HERE>>
53627	6:58:19.0005306 PM pg-agent.exe    568  Thread Exit

See the timestamps? Almost 1.5 seconds after the
wdstuff::set(_UNICODE_STRING*, char const*, bool) call, before the
signal handler thread gets woken up and kills the process.


After adding a ton of console_printf()s, I see the following (which is
displayed in the console in which gpg-agent is running, triggered when I
launch gpg2 in a separate window).

<<< gpg2 launched >>>
about to setjmp using 0x7FF8F5CC               [1]
returned from setjmp using 0x7FF8F5CC (parent) [2]
phdl=0x00880BEC, *phdl=0x00000018
attr.RootDirectory=0x00000018
h=0x000000F8 status=0x00000000
phdl closed
dup succeeded, h closed (new phdl=0x00880BEC, *phdl=0x00000018)
A
res=0
after cygheap->cwd.init()
in_forkee; skipped pthread::init_mainthread()
in_forkee; pre-forkee
in_forkee; about to longjmp using 0x00881560   [3]
returned from setjmp using 0x7FF8F5CC (child)  [2]



Which appears ok, as far as it goes. 'Course, something dies eventually
because I never do get to gpg-agent's "exec()" of pinvoke, after that fork.

[1] this is in fork(), near fork.cc:598. just before the setjmp call.
[2] this is in fork(), near fork.cc:598. just after the setjmp call.
[3] this is in dll_crt0_1(), near dcrt0.cc:840, just before the longjmp
call.

The rest of the lines are various checkpoints in dll_crt0_1()/dcrt0.cc
and in cwdstuff::set()/path.cc.

Man, this is tedious...

--
Chuck


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