public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: John Schumacher <schumjs@gmail.com>
To: Pedro Alves <pedro@codesourcery.com>
Cc: gdb@sourceware.org
Subject: Re: Thread exit error : gdb7.2 in FreeBSD (built from ports)
Date: Thu, 22 Sep 2011 22:30:00 -0000	[thread overview]
Message-ID: <CAJoUm=EwSOATcjGD8o2Y1iBe1jv6i3yvq+cNC3CNA3XJix=HdA@mail.gmail.com> (raw)

On Thu, Sep 22, 2011 at 12:11 PM, Pedro Alves <pedro@codesourcery.com> wrote:
I still don't understand this.  If this thread has exited
before, then why is the backend reporting a
TARGET_WAITKIND_STOPPED for it now?  Did a new thread reappear later
out of nothing that reuses the same ID, description and all?
If by magic that's the case, then it's this bit in
infrun.c:handle_inferior_event:
 /* If it's a new process, add it to the thread database.  */
 ecs->new_thread_event = (!ptid_equal (ecs->ptid, inferior_ptid)
                          && !ptid_equal (ecs->ptid, minus_one_ptid)
                          && !in_thread_list (ecs->ptid));
 if (ecs->ws.kind != TARGET_WAITKIND_EXITED
     && ecs->ws.kind != TARGET_WAITKIND_SIGNALLED && ecs->new_thread_event)
   add_thread (ecs->ptid);
in_thread_list returns true for an exited thread, but we should end
up in add_thread as well if ecs->ptid is in the thread list marked exited.
--
Pedro Alves


You might be on to something.
I set a breakpoint at the handle_inferior_event function in infrun.c
Notice that we handle an event for ptid.tid 100269, then proceed to
delete_thread_1. The next breakpoint we hit is for the same thread
which we had flagged as exited ptid.tid 100269. In fact, we encounter
2 of these events in a row. We then proceed to hit the error in
get_current_frame.
(gdb) c
Continuing.
Breakpoint 7, handle_inferior_event (ecs=0x7fffffffe300) at infrun.c:2989
2989      ecs->event_thread = find_thread_ptid (ecs->ptid);
(gdb) p *ecs
$109 = {
  ptid = {
    pid = 1611,
    lwp = 0,
    tid = 100269
  },
  event_thread = 0x803eade40,
  ws = {
    kind = TARGET_WAITKIND_STOPPED,
    value = {
      integer = 5,
      sig = TARGET_SIGNAL_TRAP,
      related_pid = {
        pid = 5,
        lwp = 0,
        tid = 0
      },
      execd_pathname = 0x5 Address 0x5 out of bounds,
      syscall_number = 5
    }
  },
  random_signal = 0,
  stop_func_start = 0,
  stop_func_end = 0,
  stop_func_name = 0x0,
  new_thread_event = 0,
  wait_some_more = 1
}
(gdb) p *ecs
$110 = {
  ptid = {
    pid = 1611,
    lwp = 0,
    tid = 100269
  },
  event_thread = 0x803eade40,
  ws = {
    kind = TARGET_WAITKIND_STOPPED,
    value = {
      integer = 5,
      sig = TARGET_SIGNAL_TRAP,
      related_pid = {
        pid = 5,
        lwp = 0,
        tid = 0
      },
      execd_pathname = 0x5 Address 0x5 out of bounds,
      syscall_number = 5
    }
  },
  random_signal = 0,
  stop_func_start = 0,
  stop_func_end = 0,
  stop_func_name = 0x0,
  new_thread_event = 0,
  wait_some_more = 1
}
(gdb) c
Continuing.
Breakpoint 1, delete_thread_1 (ptid=..., silent=0) at thread.c:247
247       tpprev = NULL;
(gdb) c
Continuing.
Breakpoint 6, handle_inferior_event (ecs=0x7fffffffe300) at infrun.c:2981
2981      ecs->new_thread_event = (!ptid_equal (ecs->ptid, inferior_ptid)
(gdb) p *ecs
$111 = {
  ptid = {
    pid = 1611,
    lwp = 0,
    tid = 100269
  },
  event_thread = 0x8225bb940,
  ws = {
    kind = TARGET_WAITKIND_STOPPED,
    value = {
      integer = 5,
      sig = TARGET_SIGNAL_TRAP,
      related_pid = {
        pid = 5,
        lwp = 0,
        tid = 0
      },
      execd_pathname = 0x5 Address 0x5 out of bounds,
      syscall_number = 5
    }
  },
  random_signal = 0,
  stop_func_start = 34388142208,
  stop_func_end = 34388142210,
  stop_func_name = 0x8018c13c5 "_thread_bp_death",
  new_thread_event = 0,
  wait_some_more = 1
}
(gdb)
(gdb) c
Continuing.
Breakpoint 7, handle_inferior_event (ecs=0x7fffffffe300) at infrun.c:2989
2989      ecs->event_thread = find_thread_ptid (ecs->ptid);
(gdb) p *ecs
$112 = {
  ptid = {
    pid = 1611,
    lwp = 0,
    tid = 100269
  },
  event_thread = 0x8225bb940,
  ws = {
    kind = TARGET_WAITKIND_STOPPED,
    value = {
      integer = 5,
      sig = TARGET_SIGNAL_TRAP,
      related_pid = {
        pid = 5,
        lwp = 0,
        tid = 0
      },
      execd_pathname = 0x5 Address 0x5 out of bounds,
      syscall_number = 5
    }
  },
  random_signal = 0,
  stop_func_start = 34388142208,
  stop_func_end = 34388142210,
  stop_func_name = 0x8018c13c5 "_thread_bp_death",
  new_thread_event = 0,
  wait_some_more = 1
}
(gdb) c
Continuing.
Breakpoint 3, get_current_frame () at frame.c:1177
1177          error (_("Invalid selected thread."));
(gdb) where
#0  get_current_frame () at frame.c:1179
#1  0x000000000053d5f4 in handle_inferior_event (ecs=0x7fffffffe300)
at infrun.c:3697
#2  0x000000000053ae53 in wait_for_inferior (treat_exec_as_sigtrap=0)
at infrun.c:2551
#3  0x000000000053a12c in proceed (addr=34386749296,
siggnal=TARGET_SIGNAL_0, step=0) at infrun.c:2064
This is very suspicious. Is FreeBSD calling into gdb twice for an
exiting thread? The first time, we are flagging it as exited, and
getting caught up in the get_current_frame() the second time?
Is fbsd-threads.c the one who is calling into gdb? Or how does that
relationship work?
Thanks again
-John
--
John Schumacher

             reply	other threads:[~2011-09-22 22:30 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-22 22:30 John Schumacher [this message]
  -- strict thread matches above, loose matches on Subject: below --
2011-09-14 14:27 Jusctsch
2011-09-14 14:41 ` Jusctsch
2011-09-14 15:04 ` Pedro Alves
2011-09-14 17:12   ` Jusctsch
2011-09-14 17:59     ` Pedro Alves
2011-09-22 15:49       ` Jusctsch
2011-09-22 16:34         ` Jusctsch
2011-09-22 17:11           ` Pedro Alves
     [not found]             ` <CAJoUm=HvAjAQVMVPEWs=deg0h6-m9+oMK3frD2_=bHRx+J1s5g@mail.gmail.com>
2011-09-23 19:31               ` John Schumacher

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJoUm=EwSOATcjGD8o2Y1iBe1jv6i3yvq+cNC3CNA3XJix=HdA@mail.gmail.com' \
    --to=schumjs@gmail.com \
    --cc=gdb@sourceware.org \
    --cc=pedro@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).