Re: Issue with gdbserver --multi / remote-extended on Windows XP

[Pedro Alves <pedro at codesourcery dot com>]

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

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

 http://msdn.microsoft.com/en-us/library/ms679285(VS.85).aspx
 "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.

-- 
Pedro Alves