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
