This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: How to catch GDB crash
- From: Pedro Alves <pedro at codesourcery dot com>
- To: gdb at sourceware dot org, Dmitry Smirnov <divis1969 at mail dot ru>
- Date: Tue, 24 Jun 2008 18:29:28 +0100
- Subject: Re: How to catch GDB crash
- References: <E1KBBur-000BXf-00.divis1969-mail-ru@f10.mail.ru>
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