Re: [RFA] gdb/win32-nat.c: do not call CloseHandle on process and thread handles

["Pedro Alves" <pedro_alves@portugalmail.pt>]

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