Re: Reporting the STATUS_INVALID_UNWIND_TARGET fatal error

> Date: Tue, 07 Oct 2014 18:01:47 +0100
> From: Pedro Alves <[email protected]>
> 
> 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.

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?