Pedro Alves
2014-10-07 17:01:47 UTC
In the native MinGW build of GDB, we currently do not interpret
STATUS_INVALID_UNWIND_TARGET, neither as a Posix-style signal nor as a
Windows exception (under debugexceptions). As result, GDB says
something like
gdb: unknown target exception 0xc0000029 at 0x7c9502cc
Would it make sense to report this as SIGSEGV instead?
Doesn't sound like segmentation fault, but rather theSTATUS_INVALID_UNWIND_TARGET, neither as a Posix-style signal nor as a
Windows exception (under debugexceptions). As result, GDB says
something like
gdb: unknown target exception 0xc0000029 at 0x7c9502cc
Would it make sense to report this as SIGSEGV instead?
runtime detecting some corruption. Like, e.g.,
glibc's malloc/free detecting a heap corruption and printing
about that.
This happens, e.g., when a thread tries to longjmp using stack
information recorded by a different thread. What will GDB report in
such a case on GNU/Linux or other Posix platforms?
I think nothing.information recorded by a different thread. What will GDB report in
such a case on GNU/Linux or other Posix platforms?
In absence of a more specific signal, I think SIGTRAP is the
best match, for being a "debugger" signal. This has the advantage
that SIGTRAP is not passed to the program by default, so a plain
"continue" should suppress the exception, while "signal SIGTRAP"
will pass it to the program (which I guess will usually terminate
the application).
SIGTRAP is what Valgrind's builtin gdbserver reports too when
it traps on invalid reads/writes, etc, which sounds similar to
this.
Though overall, I think it'd be better if we added a new
"target exception" waitkind or some such, and stopped trying
to masquerade Windows exceptions as Unix signals.
Thanks,
Pedro Alves