Reporting the STATUS_INVALID_UNWIND_TARGET fatal error

[Pedro Alves]

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

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

[Eli Zaretskii]

Date: Tue, 07 Oct 2014 18:01:47 +0100

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 the
runtime detecting some corruption.

But stack-related trouble, like stack overflows, are reported as
segfaults, right?

Like, e.g., glibc's malloc/free detecting a heap corruption and
printing about that.

It's not a case of corruption. Nothing is wrong with the stack per
se. In addition, it's a true exception, not a debugging feature
provided by some library. So I think it's different.

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.

Could you or someone else try?

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

You cannot continue from this exception, not on Windows anyway. Your
program dies.

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.

What would it take to do something like that?

[Pedro Alves]

Post by Eli Zaretskii

Date: Tue, 07 Oct 2014 18:01:47 +0100

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 the
runtime detecting some corruption.

But stack-related trouble, like stack overflows, are reported as
segfaults, right?

Only if they really cause a segmentation fault. Reusing the stack
of another thread would not, as that stack would be mapped in to
the process.

Post by Eli Zaretskii

Like, e.g., glibc's malloc/free detecting a heap corruption and
printing about that.

It's not a case of corruption. Nothing is wrong with the stack per
se. In addition, it's a true exception, not a debugging feature
provided by some library. So I think it's different.

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.

Could you or someone else try?

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

You cannot continue from this exception, not on Windows anyway. Your
program dies.

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.

What would it take to do something like that?

I'd try adding a new TARGET_WAITKIND_EXCEPTION, and have windows-nat.c
report that, putting the exception number in waitstatus.value.integer.
In handle_inferior_event, you'd handle it probably similarly to
TARGET_WAITKIND_NO_HISTORY, by reporting the exception and causing
a stop. To interpret the exception number, and say, convert it to
a printable string, you'd add a new gdbarch hook, that'd be
implemented in windows-tdep.c. To make the contents of the whole exception
object available to GDB and the user, I'd try adding a new convenience
variable, similar to $_siginfo or $_tlb. See windows-tdep.c for
the latter.

Thanks,
Pedro Alves