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

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

[Dr. Rolf Jansen]

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 found a solution that works for me, although, there might be better  
ways.

At line 1456 of win32-low.c I added:

       TerminateProcess (current_process_handle,
                         current_event.u.ExitProcess.dwExitCode);
       child_continue (DBG_TERMINATE_PROCESS, -1);



This code is added in event-handler switch() of  
get_child_debug_event() and the respective case block looks now like:

     case EXIT_PROCESS_DEBUG_EVENT:
       OUTMSG2 (("gdbserver: kernel event EXIT_PROCESS_DEBUG_EVENT "
		"for pid=%d tid=%x\n",
		(unsigned) current_event.dwProcessId,
		(unsigned) current_event.dwThreadId));
       ourstatus->kind = TARGET_WAITKIND_EXITED;
       ourstatus->value.integer =  
current_event.u.ExitProcess.dwExitCode;
       TerminateProcess (current_process_handle,
                         current_event.u.ExitProcess.dwExitCode);
       child_continue (DBG_TERMINATE_PROCESS, -1);
       CloseHandle (current_process_handle);
       current_process_handle = NULL;
       break;


With these changes in place, regular gui app termination works well  
with gdbserver --multi/remote-extended on Windows XP.

Best regards

Rolf

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

[Pedro Alves]

Hi,

I don't think anyone responded to this.

On Wednesday 17 September 2008 18:35:15, Dr. Rolf Jansen wrote:
> 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 found a solution that works for me, although, there might be better  
> ways.
> 
> At line 1456 of win32-low.c I added:
> 
>        TerminateProcess (current_process_handle,
>                          current_event.u.ExitProcess.dwExitCode);
>        child_continue (DBG_TERMINATE_PROCESS, -1);
> 
> 
> 
> This code is added in event-handler switch() of  
> get_child_debug_event() and the respective case block looks now like:
> 
>      case EXIT_PROCESS_DEBUG_EVENT:
>        OUTMSG2 (("gdbserver: kernel event EXIT_PROCESS_DEBUG_EVENT "
> 		"for pid=%d tid=%x\n",
> 		(unsigned) current_event.dwProcessId,
> 		(unsigned) current_event.dwThreadId));
>        ourstatus->kind = TARGET_WAITKIND_EXITED;
>        ourstatus->value.integer =  
> current_event.u.ExitProcess.dwExitCode;



>        TerminateProcess (current_process_handle,
>                          current_event.u.ExitProcess.dwExitCode);
>        child_continue (DBG_TERMINATE_PROCESS, -1);


Hmm, I haven't tried this, but, are you sure you need to
terminate the process like this?  Wouldn't a
child_continue (DBG_CONTINUE, -1) work here?  It's what
native gdb does (it's in win32_mourn_inferior).
I can't find it now, but I'm almost sure that's documented somewhere
as required for the debugger to do (I scratched my head once at why
was win32_mourn_inferior telling the dead process to continue, and found
that out).  Well, I could be wrong though.


>        CloseHandle (current_process_handle);
>        current_process_handle = NULL;
>        break;
> 
> 
> With these changes in place, regular gui app termination works well  
> with gdbserver --multi/remote-extended on Windows XP.
> 
> Best regards
> 
> Rolf
> 
> 



-- 
Pedro Alves

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

[Pedro Alves]

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

Hi,

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.

Daniel, OK to commit?

On Wednesday 05 November 2008 01:03:22, Pedro Alves wrote:
> On Wednesday 17 September 2008 18:35:15, Dr. Rolf Jansen wrote:
> > 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 found a solution that works for me, although, there might be better  
> > ways.
> > 
> > At line 1456 of win32-low.c I added:
> > 
> >        TerminateProcess (current_process_handle,
> >                          current_event.u.ExitProcess.dwExitCode);
> >        child_continue (DBG_TERMINATE_PROCESS, -1);
> > 
> > 
> > 
> > This code is added in event-handler switch() of  
> > get_child_debug_event() and the respective case block looks now like:
> > 
> >      case EXIT_PROCESS_DEBUG_EVENT:
> >        OUTMSG2 (("gdbserver: kernel event EXIT_PROCESS_DEBUG_EVENT "
> > 		"for pid=%d tid=%x\n",
> > 		(unsigned) current_event.dwProcessId,
> > 		(unsigned) current_event.dwThreadId));
> >        ourstatus->kind = TARGET_WAITKIND_EXITED;
> >        ourstatus->value.integer =  
> > current_event.u.ExitProcess.dwExitCode;
> 
> 
> 
> >        TerminateProcess (current_process_handle,
> >                          current_event.u.ExitProcess.dwExitCode);
> >        child_continue (DBG_TERMINATE_PROCESS, -1);
> 
> 
> Hmm, I haven't tried this, but, are you sure you need to
> terminate the process like this?  Wouldn't a
> child_continue (DBG_CONTINUE, -1) work here?  It's what
> native gdb does (it's in win32_mourn_inferior).
> I can't find it now, but I'm almost sure that's documented somewhere
> as required for the debugger to do (I scratched my head once at why
> was win32_mourn_inferior telling the dead process to continue, and found
> that out).  Well, I could be wrong though.
> 

-- 
Pedro Alves

[-- Attachment #2: gdbserver_mourn.diff --]
[-- Type: text/x-diff, Size: 780 bytes --]

2009-01-13  Pedro Alves  <pedro@codesourcery.com>

	* win32-low.c (get_child_debug_event): Issue a final DBG_CONTINUE
	when handling a EXIT_PROCESS_DEBUG_EVENT.

---
 gdb/gdbserver/win32-low.c |    1 +
 1 file changed, 1 insertion(+)

Index: src/gdb/gdbserver/win32-low.c
===================================================================
--- src.orig/gdb/gdbserver/win32-low.c
+++ src/gdb/gdbserver/win32-low.c
@@ -1453,6 +1453,7 @@ get_child_debug_event (struct target_wai
 		(unsigned) current_event.dwThreadId));
       ourstatus->kind = TARGET_WAITKIND_EXITED;
       ourstatus->value.integer = current_event.u.ExitProcess.dwExitCode;
+      child_continue (DBG_CONTINUE, -1);
       CloseHandle (current_process_handle);
       current_process_handle = NULL;
       break;

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

[Daniel Jacobowitz]

On Tue, Jan 13, 2009 at 04:59:48PM +0000, Pedro Alves wrote:
> Hi,
> 
> 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.
> 
> Daniel, OK to commit?

Yes, thanks.

-- 
Daniel Jacobowitz
CodeSourcery

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

[Christopher Faylor]

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?

cgf

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

[Pedro Alves]

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