From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9987 invoked by alias); 22 Nov 2007 14:37:34 -0000 Received: (qmail 9971 invoked by uid 22791); 22 Nov 2007 14:37:33 -0000 X-Spam-Check-By: sourceware.org Received: from nf-out-0910.google.com (HELO nf-out-0910.google.com) (64.233.182.189) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 22 Nov 2007 14:37:29 +0000 Received: by nf-out-0910.google.com with SMTP id b11so2536900nfh for ; Thu, 22 Nov 2007 06:37:26 -0800 (PST) Received: by 10.86.95.20 with SMTP id s20mr8529920fgb.1195742246572; Thu, 22 Nov 2007 06:37:26 -0800 (PST) Received: by 10.86.27.20 with HTTP; Thu, 22 Nov 2007 06:37:26 -0800 (PST) Message-ID: <4053daab0711220637h2bc01450ra45a19f4013fd44d@mail.gmail.com> Date: Thu, 22 Nov 2007 14:37:00 -0000 From: "Pedro Alves" To: "Pierre Muller" Subject: Re: [RFA] gdb/win32-nat.c: do not call CloseHandle on process and thread handles Cc: gdb-patches@sourceware.org In-Reply-To: <002c01c82d0f$8c789050$a569b0f0$@u-strasbg.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <002801c82d06$21bdf510$6539df30$@u-strasbg.fr> <4053daab0711220456q46cca9b4m3714c35bcc805518@mail.gmail.com> <002c01c82d0f$8c789050$a569b0f0$@u-strasbg.fr> X-Google-Sender-Auth: e9b1fb32dda8a96b 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: 2007-11/txt/msg00410.txt.bz2 Pierre Muller wrote: > > You'll still have to somehow close this process handle > (current_process_handle): > > > > /* Called in pathological case where Windows fails to send a > > CREATE_PROCESS_DEBUG_EVENT after an attach. */ > > static DWORD fake_create_process (void) { > > current_process_handle = OpenProcess (PROCESS_ALL_ACCESS, FALSE, > > current_event.dwProcessId); > > main_thread_id = current_event.dwThreadId; > > current_thread = win32_add_thread (main_thread_id, > > > current_event.u.CreateThread.hThread); > > return main_thread_id; > > } > > I don't think that anything in the testsuite checks > this case. > > > The only code location that calls this function has also some comment: > > case CREATE_THREAD_DEBUG_EVENT: > DEBUG_EVENTS (("gdb: kernel event for pid=%d tid=%x code=%s)\n", > (unsigned) current_event.dwProcessId, > (unsigned) current_event.dwThreadId, > "CREATE_THREAD_DEBUG_EVENT")); > if (saw_create != 1) > { > if (!saw_create && attach_flag) > { > /* Kludge around a Windows bug where first event is a create > thread event. Caused when attached process does not have > a main thread. */ > retval = ourstatus->value.related_pid = fake_create_process > (); > saw_create++; > } > > But what does the wording 'does not have a main thread' mean? > Is there a way to create such a process in order to try to find out > how we need to solve this issue? Try attaching to the example posted at threads/1048. > Concerning attached processes that send a CREATE_THREAD_DEBUG_EVENT first, > is the CREATE_PROCESS_DEBUG_EVENT event still sent to debugger, > but after the CREATE_THREAD_DEBUG_EVENT? > Don't know, you'll have to check, but I doubt it. It just might be easier to always open a handle to the process (OpenProcess), and not touch the one coming on the event. Then you would always close the process handle, because you know you're the one who opened it. OTTOMH, gdbserver does something similar, but leaks. This uses an extra handle on the normal case, but I don't think I'd care, as long as there are no leaks. Otherwise, you'll just have to keep a flag somewhere. -- Pedro Alves