* Reporting the STATUS_INVALID_UNWIND_TARGET fatal error
@ 2014-09-30 17:54 Eli Zaretskii
2014-10-07 17:01 ` Pedro Alves
0 siblings, 1 reply; 4+ messages in thread
From: Eli Zaretskii @ 2014-09-30 17:54 UTC (permalink / raw)
To: gdb
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?
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Reporting the STATUS_INVALID_UNWIND_TARGET fatal error
2014-09-30 17:54 Reporting the STATUS_INVALID_UNWIND_TARGET fatal error Eli Zaretskii
@ 2014-10-07 17:01 ` Pedro Alves
2014-10-07 17:25 ` Eli Zaretskii
0 siblings, 1 reply; 4+ messages in thread
From: Pedro Alves @ 2014-10-07 17:01 UTC (permalink / raw)
To: Eli Zaretskii, gdb
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Reporting the STATUS_INVALID_UNWIND_TARGET fatal error
2014-10-07 17:01 ` Pedro Alves
@ 2014-10-07 17:25 ` Eli Zaretskii
2014-10-07 17:49 ` Pedro Alves
0 siblings, 1 reply; 4+ messages in thread
From: Eli Zaretskii @ 2014-10-07 17:25 UTC (permalink / raw)
To: Pedro Alves; +Cc: gdb
> 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?
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Reporting the STATUS_INVALID_UNWIND_TARGET fatal error
2014-10-07 17:25 ` Eli Zaretskii
@ 2014-10-07 17:49 ` Pedro Alves
0 siblings, 0 replies; 4+ messages in thread
From: Pedro Alves @ 2014-10-07 17:49 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gdb
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-10-07 17:49 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-09-30 17:54 Reporting the STATUS_INVALID_UNWIND_TARGET fatal error Eli Zaretskii
2014-10-07 17:01 ` Pedro Alves
2014-10-07 17:25 ` Eli Zaretskii
2014-10-07 17:49 ` Pedro Alves
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).