Re: How to catch GDB crash

[Pedro Alves <pedro@codesourcery.com>]

A Wednesday 25 June 2008 09:02:33, Dmitry Smirnov wrote:
> Hi Pedro,
>
> I'll try to figure out, whether skyeye (which is remote target) supports
> notion of thread ids or pids. Now I just suppose it does not support.
> Nevertheless, I do not believe this is related to a crash.

Yes it is.  :-)

>
> As I said previously, I was debugging this program (ARM code) for some time
> previously. 

But you've certainly upgraded your GDB recently (I can tell by your log
output on your original post).  As I said, this is a recently introduced
regression.

I've was able to reproduce the problem, by connecting to a local
gdbserver with a GDB with all thread support hacked out in the
remote target.

> BTW, I've just realized that command-line interface does not use mi_*
> interface (neither mi_on_resume nor mi_execute_command were hit) and this
> is most likely the reason why I cannot reproduce this test case with CLI.
>

Yes, that's exactly the reason.

Anyway, I've posted a patch that fixes the issue in your case
(it was actually a side effect of something else I was doing),
although we may need to get rid of the assert you weren't tripping
at for the time being (there are other targets other than
remote that will also trip on the assert).

Vladimir, not sure if you noticed the issue, as it's buried in
this long thread?  We can always leave the crash in place to
force targets to follow our evil plot of always registering the
main thread.  :-)
I'd post a patch for it, but I don't know if we should output
thread-id=0 in that case, or not output thread-id
at all ...

-- 
Pedro Alves