This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]