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: Thread exit error : gdb7.2 in FreeBSD (built from ports)


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


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