Re: fork failure?

[Charles Wilson <cygwin at cwilson dot fastmail dot fm>]

Dave Korn wrote:
> Charles Wilson wrote:
>> the daemonized one.  If I launch <cmd line> and then attach strace to
>> the eventual pid of the daemonized process, it hangs (both strace and
>> the process).  
> 
>   How about "gdb --attach PID"?  Does that succeed?  GDB has the advantage of
> being a Cygwin rather than Win32 exe, which might make it work better when
> taking hold of the running process.

Well, since we don't support set fork-follow-child, I'm stuck in the
parent (and I don't get far enough in the child to reach a 'sleep(N)'
call, so the typical attach-after-fork approach won't work either).  And
the parent thinks everything is fine.  I haven't tried linking against a
debug-built DLL so as to step into the fork() call itself (hmm...why
aren't the cygwin1.dbg files available for the 1.7.0-nn releases? They
used to be shipped with 1.5.2x releases...) but I don't think that will
show me anything relevant. Again, I'm stuck in the parent process...

>> For some reason, if I launch the original program in
>> non-daemon mode, I can't get it to work at all, strace or not -- I'm
>> probably invoking it incorrectly, but I can't see how from the man page.
> 
>   Well, that's pretty dubious right there; I'd focus on solving that problem
> first, you want to be sure you've got all the basics correctly working before
> you try to debug it in a more complicated environment such as running daemonized.

I'm fighting a double learning curve here; it's gpg-agent from gnupg2
[*] that I'm trying to get working -- but the fork call is implemented
in the (external, static) library libassuan, so the change/rebuild/test
cycle is a PITA.  But I am not all that familiar with gpg even on linux, so:

1) odd behavior
2) is that a bug, or me screwing up, or is it supposed to do that?
3) check linux
4) hmm...go back to 1)

>> 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.
> 
>> P.S. I fear I'm doing something wrong in my cygwin CVS builds, 
> 
>   Didn't spot anything terribly suspicious there I'm afraid.
> 
>> Care to post your recipe, Dave? I'm sure it's more up-to-date than the
>> FAQ...
> 
>   It's nothing special: roughly, since I'm doing this purely from memory
> untested, it goes like so -
...
>   Then I exit my final bash shell and rename the new dll and dbg files in
> place using cmd.exe.

Thanks...I'm going to try a snapshot first with its .dbg file, then use
your recipe to build my own.

[*] requires the existing libgpg-error and libgcrypt packages, plus
(newly ported):
  libksba
  pth
  pinentry
  libassuan
  gnupg2
I can post all of these ports somewhere if somebody wants to help track
this problem down?  gpg2 itself seems to work fine.  I haven't tested
any of the smartcard/usb stuff, nor gpgsm (S/MIME enabled proggie).  I'm
just trying to get gpg-agent working.  Current behavior is:

1) launch gpg as a deamon
2) set GPG_AGENT_INFO in some shell
3) run a gpg2 command to sign something
   what ought to happen is that gpg2 tells the gpg-agent to get the
passphrase.  First gpg-agent tries to do a lookup in its cache, which
fails, and then it should try to run one of the pinentry programs [**],
you enter your passphrase, and then report the result back to gpg2.

   what DOES happen is that, while gpg2 and gpg-agent can communicate,
gpg-agent fails to fork/exec the pinentry program for entry of a
passphrase not found in gpg-agent's cache.  Confusingly, this is
reported as a problem communicating with gpg-agent -- when it isn't.
It's a problem with gpg-agent fork/execing a third program (pinentry).

Note that libksba and pth pass all tests. pinentry doesn't have any
built-in tests, but manual testing works ok [**].  libassuan fails its
one test, which is "passing file descriptors to separate processes", but
that doesn't apply here, because we;re talking about fork/exec, (e.g.
process inheritance as already handled by cygwin's fork) not completely
unrelated processes.

Oh, CRAP.

Wait.

The libassuan test ALSO uses fork/exec.  It is NOT trying to pass fds
between completely unrelated processes.  I bet if I get libassuan's test
working, that will solve the gpg-agent problem too.

Well, at least that makes the change/build/test cycle easier.  And it
means I don't need to worry about 'why can't I get gpg-agent to work in
non-daemon mode'.

[**] I've build -curses, gtk, and gtk-2. Each works standalone, if you
manually pump it with the stdin "commands" using the protocol it
normally uses to communicate with the gpg-agent.
 --
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