Message-ID: <4AD756BE.6050204@cwilson.fastmail.fm>
Date: Thu, 15 Oct 2009 13:07:10 -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>
In-Reply-To: <4AD752C8.2040908@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

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