Re: Reporting the STATUS_INVALID_UNWIND_TARGET fatal error

[Pedro Alves <palves at redhat dot com>]

On 09/30/2014 06:54 PM, Eli Zaretskii wrote:
> 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