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 13:58:20 +0100
- Subject: Re: How to catch GDB crash
- References: <E1KB7nM-000Cg0-00.divis1969-mail-ru@f94.mail.ru>
A Tuesday 24 June 2008 13:38:48, Dmitry Smirnov wrote:
> #3 0x0040b6f6 in internal_error (file=0x62380b ".././gdb/mi/mi-interp.c",
> line=340, string=0x6237ed "%s: Assertion `%s' failed.") at utils.c:818
> #4 0x0048cfec in mi_on_resume (ptid={pid = 42000, lwp = 0, tid = 0})
> at .././gdb/mi/mi-interp.c:340
42000 looks a lot like remote.c:MAGIC_NULL_PID, and it wasn't on the
thread list at this point:
static void
mi_on_resume (ptid_t ptid)
{
if (PIDGET (ptid) == -1)
fprintf_unfiltered (raw_stdout, "*running,thread-id=\"all\"\n");
else
{
struct thread_info *ti = find_thread_pid (ptid);
gdb_assert (ti); <<<<<<<<<<<< assert here
fprintf_unfiltered (raw_stdout, "*running,thread-id=\"%d\"\n", ti->num);
}
}
And, it looks like your stub does not implement any thread support?
It seems we either need to make sure remote.c always registers
a thread, or remove that assert. I would prefer the former,
as it's a requirement to getting rid of context switching
on the core side.
--
Pedro Alves