Re: How to catch GDB crash

[Dmitry Smirnov <divis1969@mail.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
>