This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: How to catch GDB crash
- From: Dmitry Smirnov <divis1969 at mail dot ru>
- To: Pedro Alves <pedro at codesourcery dot com>
- Cc: gdb at sourceware dot org
- Date: Thu, 26 Jun 2008 18:32:46 +0400
- Subject: Re: How to catch GDB crash
- References: <200806261520.54671.pedro@codesourcery.com>
- Reply-to: Dmitry Smirnov <divis1969 at mail dot ru>
Ok, you'd convinced me :-)
You are right, the last resume() is executed with stepping_over_breakpoint equal to 1 whereas previously it was 0.
I'll try your patch (I can find it in gdb-patches, right?).
Dmitry
-----Original Message-----
From: Pedro Alves <pedro@codesourcery.com>
To: gdb@sourceware.org, Dmitry Smirnov <divis1969@mail.ru>
Date: Thu, 26 Jun 2008 15:20:54 +0100
Subject: Re: How to catch GDB crash
>
> A Thursday 26 June 2008 14:56:26, Dmitry Smirnov wrote:
> > I still have some doubts :-)
> >
>
> Well, the doubts would go away if you tried the patches. :-)
>
> I'm hoping to get to commit them today, though...
>
> > Below is a new log of my debug session. I've set the same
> > mi_execute_command and mi_on_resume. Last one prints the value of
> > 'inferior_ptid' when hit. Also, from Eclipse I've issues command 'ni'
> > before 'c'. As you can see, 'inferior_ptid' it is equal to {pid = 42000,
> > lwp = 0, tid = 0} all the time whereas mi_on_resume is called with {pid =
> > -1, lwp = 0, tid = 0} in all cases except last one.
> >
> > On my mind it indicates that while executing last 'ni', function resume()
> > in file infrun.c goes different way and it assigned 'inferior_ptid' to
> > 'resume_ptid' instead of default RESUME_ALL.
>
> Did you actually look at the function that is asserting? Here it is again:
>
> 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);
> fprintf_unfiltered (raw_stdout, "*running,thread-id=\"%d\"\n", ti->num);
> }
> }
>
> Calling the resume functions with {-1,0,0} means "let all threads execute",
> while with {42000,0,0} meant, "let only this thread execute". This last
> case happens normally when GDB is trying to step over a breakpoint:
>
> - remove breakpoints
> - step only the thread of interest, leaving others stopped, so if they happen
> to be executing the same code, they don't miss the breakpoint
> - reinsert breakpoints
> - now safe to resume all threads
>
> It just happens that in your case there's only one "thread" always,
> but the core of inferior control in GDB doesn't care and sends {42000,0,0}
> anyway. The problem was that this assert is there because this function
> assumes threads are always registered in the thread table, while that
> is unfortunatelly still not always true throughout all of GDB's supported
> targets.
>
> > Breakpoint 1, mi_on_resume (ptid={pid = 42000, lwp = 0, tid = 0})
> > at .././gdb/mi/mi-interp.c:335
> > 335 if (PIDGET (ptid) == -1)
> > $3 = {pid = 42000, lwp = 0, tid = 0}
> >
> > Program exited with code 037777777777.
> > (gdb)
>
> --
> Pedro Alves
>