Reporting the STATUS_INVALID_UNWIND_TARGET fatal error

Reporting the STATUS_INVALID_UNWIND_TARGET fatal error

[Eli Zaretskii]

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?

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?

Re: Reporting the STATUS_INVALID_UNWIND_TARGET fatal error

[Pedro Alves]

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

Re: Reporting the STATUS_INVALID_UNWIND_TARGET fatal error

[Eli Zaretskii]

> Date: Tue, 07 Oct 2014 18:01:47 +0100
> From: Pedro Alves <palves@redhat.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.

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?

Re: Reporting the STATUS_INVALID_UNWIND_TARGET fatal error

[Pedro Alves]

On 10/07/2014 06:26 PM, Eli Zaretskii wrote:
>> Date: Tue, 07 Oct 2014 18:01:47 +0100
>> From: Pedro Alves <palves@redhat.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.
> 
> 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.

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