RE: New mingw32 support problems

["Pierre Muller" <muller at ics dot u-strasbg dot fr>]

 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
events.

This comes from Microsoft docs online:
http://msdn2.microsoft.com/en-us/library/ms679285.aspx

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.

  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 am currently trying to understand how to 
tell the system not to pass those STATUS_INVALID_HANDLE down
to the debuggee, and the code seems to work more or less now.

 I will post a RFC in a separate email

Pierre  

> -----Original Message-----
> From: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] On
> Behalf Of Pedro Alves
> Sent: Friday, October 19, 2007 2:59 AM
> To: Eli Zaretskii
> Cc: Pierre Muller; gdb@sourceware.org; brobecker@adacore.com
> Subject: Re: New mingw32 support problems
> 
> Eli Zaretskii wrote:
> >> From: "Pierre Muller" <muller@ics.u-strasbg.fr>
> >> Date: Thu, 18 Oct 2007 09:34:50 +0200
> >>
> >> During symbol reading, struct/union type gets multiply defined:
> struct type.
> >> Breakpoint 1 at 0x40bc07: file ../../src/gdb/utils.c, line 817.
> >> Breakpoint 2 at 0x41932f: file ../../src/gdb/cli/cli-cmds.c, line
> 199.
> >
> > No clue about this one.
> >
> >> gdb: unknown target exception 0xc0000008 at 0x7c90eb74
> >>
> >> Program received signal ?, Unknown signal.
> >
> > I think this is because GDB does not support Windows exception codes,
> > see the various STATUS_* constants in winbase.h.  0xc0000008 is
> > invalid handle.
> >
> 
> A few comments:  I won't have much time to help debug this in the
> comming days.
> 
> That's correct.  When an invalid handle is passed to the win32 api
> function `CloseHandle', and iff a debugger is attached, an
> EXCEPTION_INVALID_HANDLE first chance exception will be thrown.  This
> is a debugging api feature.  It would be somewhat like the unix
> equivalent of giving gdb the ability to trap syscalls with
> invalid args.
> 
> Pierre's launched:
> 
> gdb1
>   +-----gdb2
>          +-----gdb3
> 
> In this case, gdb2 is issuing an invalid CloseHandle, and gdb1 is
> seeing it in the form of an EXCEPTION_INVALID_HANDLE.
> I could reproduce it here, and I noticed it is even easier to
> reproduce (no need to quit) it if we use "set new-console 1" in
> all the gdbs.  I bet that gdb3 could be replaced with something
> else, and the "problem" would still trigger.
> 
> This exception, being a debugger api facility, shouldn't
> be passed to the inferior, which naturally doesn't handle it,
> thus resulting in the second chance exception, this time
> caught by gdb as:
> 
> gdb: unknown target exception 0xc0000008 at 0x7c90eb74
> "Program received signal ?, Unknown signal."
> 
> But, this time, it is too late to ignore the exception, the
> inferior is going to have to die.
> That would be the equivalent of having a 'close(-1);' kill
> the inferior instead of just setting errno.
> 
> I don't know why this triggers on a MinGW gdb and not on
> a Cygwin gdb.  From the trace, it seems that is it something
> inside Windows that is borking it.  The normal case is to
> have the exception thrown from inside
> 0x7C90EB74
> 
> Maybe we are indeed
> corrupting something that manifests like this, or maybe we
> aren't.  I hacked win32-nat.c to ignore it and nothing
> bad happened.  gdb1, gdb2 and gdb3 continued working
> as expected.
> 
> Adding proper support for stopping and resuming/passing/ignoring
> win32 first chance exceptions support into gdb would be a nice
> project.
> A quick alternative would be to eat a first chance
> EXCEPTION_INVALID_HANDLE that comes from inside ntdll.dll.
> Since we won't be doing anything useful with it,
> we might as well silence it ...  dunno.
> 
> >> gdb: unknown target exception 0xc0000008 at 0x7c90eb74
> >
> > So it looks like Cygwin also doesn't support these exceptions?
> >
> 
> It doesn't.
> 
> Cheers,
> Pedro Alves