RE: debugging across fork

[Andrew Dalgleish <andrewd@axonet.com.au>]

> -----Original Message-----
> From:	Mumit Khan [SMTP:khan@xraylith.wisc.EDU]
> Sent:	Friday, August 27, 1999 14:41
> To:	Andrew Dalgleish
> Cc:	'cygwin@sourceware.cygnus.com'
> Subject:	Re: debugging across fork 
> 
> Andrew Dalgleish <andrewd@axonet.com.au> writes:
> > 
> > 
> > > 
> > > btw, I finally ran the cygwin build and noticed that the balloon
> > > popups don't work when I position the pointer on say a variable.
> > > If it happens to others as well, it's probably a bug and needs
> > > to be reported. Works fine on Unix boxes I've tried.
> > [Andrew Dalgleish]  
> > I had noticed that.
> > If you hover over a function name the popup does show the function
> > address.
> 
> Ah, it's the old bug where the files are not on C: drive. If the
> source files are on C:, then everything works (functions and vars),
> otherwise nothing.  Essentially gdb_loc chokes if files are named
> say //g/foo.c or g:\\foo.c (the actual error is "No source file
> named `xxx' in decode_line_1 deep within the guts).
[Andrew Dalgleish]  
My root mount is U:/ (a subst drive), so you are probably correct.

I am now able to commence debugging this problem.
It just took me a while to realize I had to look up the child's
*windows* pid to attach.

For the benefit of those searching the archive, to use gdb attach you
need to run 'ps -l'.

I was hoping to do this, but my main bash window exits after starting
foo.
gdb foo &
(step until after fork)
ps -l
(look up child's windows pid)
gdb foo.exe 123



What did work for me (using Insight) was this:
./foo &
(after foo forks, the parent prints the child id, and the child does a
sleep(60))
ps -l
(look up child's windows pid)
gdb foo.exe 123


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com