This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: How to catch GDB crash
- From: Vladimir Prus <vladimir at codesourcery dot com>
- To: Pedro Alves <pedro at codesourcery dot com>
- Cc: gdb at sourceware dot org, Dmitry Smirnov <divis1969 at mail dot ru>
- Date: Tue, 1 Jul 2008 15:37:35 +0400
- Subject: Re: How to catch GDB crash
- References: <200806241829.29427.pedro@codesourcery.com> <E1KBPxZ-0008HB-00.divis1969-mail-ru@f62.mail.ru> <200806260027.59248.pedro@codesourcery.com>
On Thursday 26 June 2008 03:27:58 Pedro Alves wrote:
> 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 ...
I think that for the time being, we can change the assert to check that
either the program is single-threaded, or the thread is known. If the
program is single-threaded, the the thread id is not registered, omitting
thread-id completely seems right.
I can make this change, or you have something already?
- Volodya