Debugging sub-processes with gdb

Debugging sub-processes with gdb

[Henry S. Thompson]

I'm trying to debug a problem with xemacs that involves the child
process forked when you execute M-x shell.

None of the mechanisms in the gdb documentation for choosing to step
into the child process (instead of the parent) after a fork() seem to
work for me.  That is, in particular, setting follow-for-mode to child
still leaves me in the parent after stepping over a fork().

Setting detach-on-fork to 'off' also seems to have no effect.

Have I misunderstood something, or does this aspect of gdb just not
work under cygwin (x86_64, 1.7.29-2)?

Thanks,

ht
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

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

Re: Debugging sub-processes with gdb

[Christopher Faylor]

On Wed, May 14, 2014 at 04:10:36PM +0100, Henry S. Thompson wrote:
>I'm trying to debug a problem with xemacs that involves the child
>process forked when you execute M-x shell.
>
>None of the mechanisms in the gdb documentation for choosing to step
>into the child process (instead of the parent) after a fork() seem to
>work for me.  That is, in particular, setting follow-for-mode to child
>still leaves me in the parent after stepping over a fork().
>
>Setting detach-on-fork to 'off' also seems to have no effect.
>
>Have I misunderstood something, or does this aspect of gdb just not
>work under cygwin (x86_64, 1.7.29-2)?

Debugging subprocesses doesn't work for Windows gdb.  Sorry.

If you have control over the code you could have it print a pid, wait,
and then attach to it with gdb.  That works.

cgf

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

Re: Debugging sub-processes with gdb

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1164 bytes --]

On May 14 16:10, Henry S. Thompson wrote:
> I'm trying to debug a problem with xemacs that involves the child
> process forked when you execute M-x shell.
> 
> None of the mechanisms in the gdb documentation for choosing to step
> into the child process (instead of the parent) after a fork() seem to
> work for me.  That is, in particular, setting follow-for-mode to child
> still leaves me in the parent after stepping over a fork().
> 
> Setting detach-on-fork to 'off' also seems to have no effect.
> 
> Have I misunderstood something, or does this aspect of gdb just not
> work under cygwin (x86_64, 1.7.29-2)?

No, it doesn't, it has never been implemented.  This would require
some extensions to GDB as well as the Cygwin DLL, given that Windows
is not quite up to speed in terms of fork.

As a workaround, you could tweka emacs to sleep at certain points in the
code, and then attach to the child process with a second GDB.  Granted,
it's a bit of a hassle, but it works.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Debugging sub-processes with gdb

[LRN]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 14.05.2014 19:25, Christopher Faylor wrote:
> On Wed, May 14, 2014 at 04:10:36PM +0100, Henry S. Thompson wrote:
>> I'm trying to debug a problem with xemacs that involves the child 
>> process forked when you execute M-x shell.
>> 
>> None of the mechanisms in the gdb documentation for choosing to step 
>> into the child process (instead of the parent) after a fork() seem to 
>> work for me.  That is, in particular, setting follow-for-mode to child 
>> still leaves me in the parent after stepping over a fork().
>> 
>> Setting detach-on-fork to 'off' also seems to have no effect.
>> 
>> Have I misunderstood something, or does this aspect of gdb just not work
>> under cygwin (x86_64, 1.7.29-2)?
> 
> Debugging subprocesses doesn't work for Windows gdb.  Sorry.
> 
> If you have control over the code you could have it print a pid, wait, and
> then attach to it with gdb.  That works.

What i do in these cases:
1) Find the call to CreateProcess() that spawns the child (if it uses some
kind of _spawn() instead, you're screwed)
2) Add a breakpoint (b1) before the call and a breakpoint (b2) after the call
3) commands b1
set createprocessflags=createprocessflags | 4
c
end

(replace createprocessflags with the variable used to hold the flags)
4) commands b2
p processinfo.dwProcessId
end

(replace processinfo with the variable used to hold handles and IDs for
spawned child process/thread)

This way all processes will be spawned in suspended state (that's what 4 is
for), and gdb will stop on a breakpoint after the call to wait for you to
figure out what to do. If you want to debug the child, re-attach gdb to it,
or launch a new gdb instance and attach that one. In either case, add a
breakpoint at main, then continue. Once that is done, use ProcessHacker (or
anything similar) to Resume the suspended child process. If the child itself
spawns children you want to debug, repeat these steps there as well.

I was able to debug ld.exe this way (it is spawned by collect2.exe, which is
spawned by gcc.exe).

- -- 
O< ascii ribbon - stop html email! - www.asciiribbon.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)

iQEcBAEBAgAGBQJTc4z5AAoJEOs4Jb6SI2CwLokIAOHl4OnE6AmqI5VX92u27EEL
Mhmr3/QF8N3NkH6lJJmydk5aczEyfq65Xh2LYJsfUhZ8YWSvqQYHZhnQHQ38JIYR
LrlatzKswRbpSphal3VfVIEyrMaK1vACWJSC0hzScDd+JPSL399i1hGgTE2rEYoV
6b4jLRAZIM3H5N3OyeUctqL11JSZsKEhxWUM0APMmMbyrFBS4+hxDF09Lxv3VnQU
5mA2OFE6r7yXt+ju4lo0zSWmJ1+jjY2ikIW1ngD88Z2P2TIkfrEOSUZS4SWvt0O8
JJHokW5Y5PO3D7v+I0VwcC6Rjqn8dnNK5H6aO3u1QxUowrARNc+SbL7WeT8mt/I=
=TAj2
-----END PGP SIGNATURE-----

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

Re: Debugging sub-processes with gdb

[Henry S. Thompson]

Christopher Faylor writes:

> On Wed, May 14, 2014 at 04:10:36PM +0100, Henry S. Thompson wrote:
>>I'm trying to debug a problem with xemacs that involves the child
>>process forked when you execute M-x shell.
>>
>>None of the mechanisms in the gdb documentation for choosing to step
>>into the child process (instead of the parent) after a fork() seem to
>>work for me.  That is, in particular, setting follow-for-mode to child
>>still leaves me in the parent after stepping over a fork().
>>
>>Setting detach-on-fork to 'off' also seems to have no effect.
>>
>>Have I misunderstood something, or does this aspect of gdb just not
>>work under cygwin (x86_64, 1.7.29-2)?
>
> Debugging subprocesses doesn't work for Windows gdb.  Sorry.

Thanks for confirming.

> If you have control over the code you could have it print a pid, wait,
> and then attach to it with gdb.  That works.

Understood, will do.

ht
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

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

Re: Debugging sub-processes with gdb

[Christopher Faylor]

On Wed, May 14, 2014 at 04:36:59PM +0100, Henry S. Thompson wrote:
>Christopher Faylor writes:
>> If you have control over the code you could have it print a pid, wait,
>> and then attach to it with gdb.  That works.
>
>Understood, will do.

I should have mentioned, as an alternative approach, if you're willing
to rebuild the Cygwin DLL, you can configure and build it with
--enable-debugging.  Then you can set an environment variable
CYGWIN_DEBUG=xemacs

That will start a gdb sessions every time Cygwin runs a program
with 'xemacs' in its name.

Be advised however that --enable-debugging adds some check to the cygwin
dll which can slow it down noticeably and, in some rare situations,
introduce some races which cause crashes that you wouldn't see with
the non-debugging variant.

cgf

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