This is the mail archive of the
mailing list for the GDB project.
Re: Issue with gdbserver --multi / remote-extended on Windows XP
- From: Pedro Alves <pedro at codesourcery dot com>
- To: "Dr. Rolf Jansen" <rj at surtec dot com>
- Cc: Daniel Jacobowitz <drow at false dot org>, gdb-patches at sourceware dot org
- Date: Tue, 13 Jan 2009 18:22:03 +0000
- Subject: Re: Issue with gdbserver --multi / remote-extended on Windows XP
- References: <E9B56D18-AB65-4F0A-A491-AF6C47A731AD@surtec.com> <email@example.com> <20090113175734.GB3096@ednor.casa.cgf.cx>
On Tuesday 13 January 2009 17:57:34, Christopher Faylor wrote:
> On Tue, Jan 13, 2009 at 04:59:48PM +0000, Pedro Alves wrote:
> >Rolf told me that this does indeed work as expected. I just finished a
> >testsuite run against a native cygwin gdbserver on XP, and spotted no
> Maybe gdbserver should be using "DebugSetProcessKillOnExit (true)" for
> systems which support it?
Hmm, this is not about gdbserver exiting and killing the inferior. This is
the case of the inferior exiting and gdbserver still being alive waiting
for a new connection after the inferior exits -- that's what
gdbserver --multi / extended-remote buys you.
We were missing a required ContinueDebugEvent after handling a process
exit. gdb/windows-nat.c also does it, in windows_mourn_inferior.
From the OP's original report:
"I experimented a little bit with gdbserver --multi in remote-xtended
mode on Windows XP and I had one major problem in debugging a gui
application. If I regularly quit the gui app, to which gdbserver is
attached, its open windows remain at the screen, and while although
inresponsive they are still part of the window hierarchy of Windows.
- the gui app is terminates itself by calling exit(0).
- if I quit gdbserver, the open zombie-windows disappear
- in non-multi/remote-extended-mode gdbserver this problem
does not appear, because gdbserver terminates itself
together with the application
I thought that "DebugSetProcessKillOnExit(true)" was the default, and
that "true" was the behaviour on systems that don't support
that call anyway?
I can almost swear I saw that we need to call ContinueDebugEvent explicitly
documented somewhere, but I can't find it again. I do see things like this:
"If the continued thread previously reported an EXIT_PROCESS_DEBUG_EVENT
debugging event, ContinueDebugEvent closes the handles the debugger has to
the process and to the thread."
This strongly suggests that the symptoms Ralf was seeing are a manifestation
of some handles being left open.
There were also some patches from Pierre that cleaned up a few handle
leaks in windows-nat.c last year that I don't think were never ported
to gdbserver, which sound similar/related to this.