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
