Re: Reporting the STATUS_INVALID_UNWIND_TARGET fatal error

[Pedro Alves <palves@redhat.com>]

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