From: Christopher Faylor <cgf-use-the-mailinglist-please@sourceware.org>
To: gdb-patches@sourceware.org, Pierre Muller <muller@ics.u-strasbg.fr>
Subject: Re: [RFA] win32-nat.c: Restore wrongly removed code that closes two handles returned by CreateProcess
Date: Fri, 11 Jan 2008 18:32:00 -0000 [thread overview]
Message-ID: <20080111183146.GA27708@ednor.casa.cgf.cx> (raw)
In-Reply-To: <001301c85476$4eff2fc0$ecfd8f40$@u-strasbg.fr>
On Fri, Jan 11, 2008 at 06:20:48PM +0100, Pierre Muller wrote:
> This patch restores two lines of code that I wrongfully
>removed in a previous patch about problems related to
>closing of handles that the system should close.
>
>The applied patch is:
>http://sourceware.org/ml/gdb-patches/2007-11/msg00481.html
>
> In that patch,
> I also removed two calls to CloseHandle functions for the two
>handles that are returned by the CreateProcess function.
>To make things worse, I forgot to mention that
>removal in the corresponding ChangeLog.
>
>The wrong part of the patch is in win32_create_inferior
>@@ -1886,9 +1893,6 @@ win32_create_inferior (char *exec_file,
> error (_("Error creating process %s, (error %d)."),
> exec_file, (unsigned) GetLastError ());
>
>- CloseHandle (pi.hThread);
>- CloseHandle (pi.hProcess);
>-
> if (useshell && shell[0] != '\0')
> saw_create = -1;
> else
>
> I was supposing that the handles returned by
>CreateProcess in the ProcessInformation structure
>were the same as the handles given in the
>initial CREATE_PROCESS_DEBUG_EVENT.
> But these two handles are completely separate, as
>printing out the values enabled me to see. The handles
>returned by CreateProcess are given to any program
>launching another executable, while the other handles are debugger
>specific.
>
> The purpose of that patch was about avoiding to close the handles
>that are given on debug events, as stated in the windows API
>documentation. But the same docs do specify that
>the two handles returned in the ProcessInformation structure
>need to be closed.
>
> I ran the testsuite on that patch and found no
>change, but the missing CloseHandle calls might still
>have some influence on other cases.
> Luckily no gdb release contains that error.
>
> Christopher, should I modify the ChangeLog-2007 entry
>that contains the bad removal of that code, as
>the entry is incomplete?
No, AFAIK, you are not supposed to retroactively change a ChangeLog
entry like that.
> Sorry about this mistake,
No need to apologize! I'm glad you caught this and I'm glad that you
researched your earlier changes. I actually stumbled across your
initial bug separately last week while debugging something with an older
version of gdb. So, I'm happy that you fixed it.
>ChangeLog entry:
>
>2008-01-11 Pierre Muller <muller@ics.u-strasbg.fr>
>
> * win32-nat.c (win32_create_inferior): Restore
> code calling CloseHandle on ProcessInformation structure.
Please check in. I'm sorry that I didn't catch this when I reviewed
your change. It's obvious in perfect 20-20 hindsight.
cgf
next prev parent reply other threads:[~2008-01-11 18:32 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-11 17:21 Pierre Muller
2008-01-11 18:32 ` Christopher Faylor [this message]
2008-01-14 8:03 ` Pierre Muller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080111183146.GA27708@ednor.casa.cgf.cx \
--to=cgf-use-the-mailinglist-please@sourceware.org \
--cc=gdb-patches@sourceware.org \
--cc=muller@ics.u-strasbg.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox