This is the mail archive of the
mailing list for the Cygwin project.
Re: fork failure?
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
> 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
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
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
[**] 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.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple