This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: New mingw32 support problems

Pierre Muller wrote:
>  I think that I found the reason of the behavior difference
> between cygwin and mingw32 compiled GDBs.
>   Cygwin installs an exception handler in cygwin1.dll
> that has the following code:
> winsup/cygwin/ around line 550 in current cvs src tree:
>       /* CloseHandle will throw this exception if it is given an
>          invalid handle.  We don't care about the exception; we just
>          want CloseHandle to return an error.  This can be revisited
>          if gcc ever supports Windows style structured exception
>          handling.  */
>       return 0;
> while mingw32 installs apparently no exception handler
> at all.
>    The problem seems to be coming from the fact that
> GDB is closing some handles that it should not close
> according to the win32 API.
>    This is especially the case for the thread handles,
> that are normally closed by the system after
> events.
> This comes from Microsoft docs online:
> After the ContinueDebugEvent function succeeds, the specified thread
> continues. Depending on the debugging event previously reported by the
> thread, different actions occur. If the continued thread previously reported
> an EXIT_THREAD_DEBUG_EVENT debugging event, ContinueDebugEvent closes the
> handle the debugger has to the thread. 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 explanation fits so right to the symptons, that I can't see
how it can't be it.  :)

I've seen something of the sort in Windows CE.  There's currently this beauty
in gdbserver/win32-low.c:

#ifndef _WIN32_WCE
  /* On Windows CE this handle can't be closed.  The OS reuses
     it in the debug events, while the 9x/NT versions of Windows
     probably use a DuplicateHandle'd one.  */
  CloseHandle (pi.hThread);

Seems like it was another manifestation of the same API usage violation?

>   But I vaguely remember that those calls where added for some good
> reasons to the win32-nat.c source. Maybe the closing by the system
> is version dependent...

I remember reading something about having handles to the executable open
would prevent updating it in place?  Could it be that just fixing the
thread CloseHandles fixes the issue?

Pedro Alves

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]