This is the mail archive of the gdb@sourceware.org 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


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


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