This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: fork failure?

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
h=0x000000F8 status=0x00000000
phdl closed
dup succeeded, h closed (new phdl=0x00880BEC, *phdl=0x00000018)
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 just before the setjmp call.
[2] this is in fork(), near just after the setjmp call.
[3] this is in dll_crt0_1(), near, just before the longjmp

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

Man, this is tedious...


Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]