Re: How to catch GDB crash

[Dmitry Smirnov <divis1969 at mail dot ru>]

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.

As I said previously, I was debugging this program (ARM code) for some time previously. It is very complex program, it consists of several ELF files. Before this one, I've debugged couple more. I've used 'ni' and/or -exec-next-instruction a lot and didn't see a lot crashes. I remember that I've seen couple of them (in similar scenario: when I've set a BP and run till it hits) but I had eliminated it by moving the breakpoint to another location. 
It is just feeling, no more, that crash is somehow connected with stack trace: previously I didn't see much stack traces. In most cases there was 2 or 3 frames (in fact, call stack should have more frames, but GDB was not able to correctly detect frames. This may be caused by assembler code which does not follow ABI).

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.

Dmitry

-----Original Message-----
From: Pedro Alves <pedro@codesourcery.com>
To: gdb@sourceware.org,  Dmitry Smirnov <divis1969@mail.ru>
Date: Tue, 24 Jun 2008 18:29:28 +0100
Subject: Re: How to catch GDB crash

> 
> A Tuesday 24 June 2008 18:02:49, Dmitry Smirnov wrote:
> > As you can see, first time 
> > mi_on_resume is called with ptid={pid = -1, lwp = 0, tid = 0}. Something
> > happens between this call and second call where ptid={pid = 42000, lwp = 0,
> > tid = 0}.
> >
> > I'm going to figure out which command is followed by wrong pid. I'm
> > suspecting memory corruption.
> 
> This pid is used by GDB internally when you are connected to a target
> that does not support threads at all, like small embedded systems.
> If the remote side doesn't have a notion of thread ids or pids, that
> magic number is what GDB will use internally.  This code path can
> be triggered for example while stepping over a breakpoint (doing
> nexti / -exec-next-instruction while stopped at a breakpoint).
> 
> > BTW, command 'info threads' gives me
> >   (gdb) info threads
> >   warning: RMT ERROR : failed to get remote thread list.
> 
> ... which this seems to corroborate.
> 
> This is a new bug in GDB that was introduced recently.
> 
> I've already said in my last reply what needs to be done
> to fix it.
> 
> If your target *does* support threads and the remote protocol
> thread related packets, than there's yet another bug somewhere
> else.
> 
> -- 
> Pedro Alves
>