Re: fork failure?

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

Dave Korn wrote:
> Charles Wilson wrote:
> 
>> ModLoad: 75bd0000 75c7a000   C:\Windows\system32\msvcrt.dll
> 
>   Say, what's that doing there?  Might like to check who's pulling it in, just
> in case something's gone all win32 on you that shouldn't be.

It appears to be pulled in by winsock2, which is on-demand loaded by
cygwin, so it doesn't show up in the explicit dependencies as reported
by cygcheck.  But that's all "behind the cygwin layer" -- the way I've
built gnupg2 and libassuan, they don't go behind cygwin's back to access
windows socket functions directly. They use cygwin functionality for that.

>> ModLoad: 6c1b0000 6c1b5000   C:\Windows\system32\avgrsstx.dll
> 
>   Let's hope AVG hasn't gone (even further) over to the dark side.

Aw geez.  I tried running with AVG both enabled and disabled (but not
uninstalled).  There was a difference in the ProcMon output -- obviously
the disabled AVG makes fewer syscalls -- but the gpg-agent behavior was
unchanged.

I guess I'll try to uninstall AVG and see if that makes a difference.

>> which is just after the output window gets:
>> returning from fork: ischild=1, res=0
>>
>> So, this is the right spot.  And $eip is 0x0.  That doesn't tell me much...
> 
>   So, the dreaded jump-to-zero.  Always a tricky one, since by the time you
> get there you have no idea where you came there from.  Except that we suspect
> fork().  I'd set a breakpoint on the start of fork and another one on the ret
> at the end of it, (did you try mingw gdb yet? 

Not yet. Chris S. has recently released an updated mingw gdb based on
7.0, but I haven't installed or tested that one yet.

> it might be easier here than
> windbg since it'll understand the symbols, but if you can't get it to work
> then you can manually look up symbol addresses and set the breakpoints by hex
> address), 

Well, I did this in windbg (manually setting breakpoints).
Unfortunately, they appeared to have no effect -- after "g", it blew
right past them and into the exception.  Maybe I'll have better luck
with mingw-gdb.

First I'm going to rip out a lot of the debugging cruft from my cygwin
DLL, now that I know (part of) it was a wild goose chase.

> and then I'd restart the program, note the value of $esp and verify
> a sane-looking return address on entry to the function, let it run to the end
> of the function and find out if the stack pointer wasn't back at the same
> location or if the return address there had been corrupted.

Ah. Well...that won't actually work.  The *parent* is the only one of
the two that actually /enters/ the fork() function in the normal way,
and thus could be expected to have a reasonable return address (and hit
a breakpoint at the beginning of the function).

The child...not so much. It "enters" fork() by way of the longjmp, using
the jmb_buf set by the parent when IT was inside fork(), before the
parent (via a roundabout method) called CreateProcess to create the
child in the first place.

I suppose I could debug both the parent AND the child: since the forkee
should have exactly the same memory layout (and stack trace) once they
return from fork(), I suppose that I could

  1) look at the parent's stack trace when it is inside fork(). Ditto
     its return address.
  2) after the child longjmp's back into fork() from dll_crt0_1,
     look at its stack trace and return address. (although I can't
     really catch it that early. I can only catch it in the debugger
     just after the CYGWIN_FORK_SLEEP...but at least I'm still
     back inside fork() at that point.

They ought to match in all respects, correct?

> The second of
> those could potentially be tracked down using a hardware breakpoint
> (watchpoint in gdb terminology), the first of those two would require reading
> the code to see why it's not popping and pushing in equal amounts.

But setjmp and longjmp are nasty black magic assembly generated by
winsup/cygwin/gendef... Ow! Stop! That hurts!

--
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