From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32158 invoked by alias); 13 Jan 2009 18:22:21 -0000 Received: (qmail 32150 invoked by uid 22791); 13 Jan 2009 18:22:20 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,SPF_PASS,ZMIde_GENERICSPAM1 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 13 Jan 2009 18:21:44 +0000 Received: (qmail 8568 invoked from network); 13 Jan 2009 18:21:42 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 13 Jan 2009 18:21:42 -0000 From: Pedro Alves To: "Dr. Rolf Jansen" Subject: Re: Issue with gdbserver --multi / remote-extended on Windows XP Date: Tue, 13 Jan 2009 18:22:00 -0000 User-Agent: KMail/1.9.10 Cc: Daniel Jacobowitz , gdb-patches@sourceware.org References: <200901131659.48833.pedro@codesourcery.com> <20090113175734.GB3096@ednor.casa.cgf.cx> In-Reply-To: <20090113175734.GB3096@ednor.casa.cgf.cx> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200901131822.04437.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-01/txt/msg00286.txt.bz2 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. >=20 > 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. =46rom the OP's original report: "I experimented a little bit with gdbserver --multi in remote-xtended=20=20 mode on Windows XP and I had one major problem in debugging a gui=20=20 application. If I regularly quit the gui app, to which gdbserver is=20=20 attached, its open windows remain at the screen, and while although=20=20 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. --=20 Pedro Alves