This is the mail archive of the
mailing list for the GDB project.
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/exceptions.cc around line 550 in current cvs src tree:
> case STATUS_INVALID_HANDLE:
> /* 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
> the EXIT_THREAD_DEBUG_EVENT and EXIT_PROCESS_DEBUG_EVENT
> 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
/* 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. */
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?