public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
* Re: Thread exit error : gdb7.2 in FreeBSD (built from ports)
@ 2011-09-22 22:30 John Schumacher
  0 siblings, 0 replies; 10+ messages in thread
From: John Schumacher @ 2011-09-22 22:30 UTC (permalink / raw)
  To: Pedro Alves; +Cc: gdb

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

^ permalink raw reply	[flat|nested] 10+ messages in thread
* Thread exit error : gdb7.2 in FreeBSD (built from ports)
@ 2011-09-14 14:27 Jusctsch
  2011-09-14 14:41 ` Jusctsch
  2011-09-14 15:04 ` Pedro Alves
  0 siblings, 2 replies; 10+ messages in thread
From: Jusctsch @ 2011-09-14 14:27 UTC (permalink / raw)
  To: gdb


Hello all,
I have been running into a particularly interesting issue.
When a thread exits in the application gdb is running, that exit doesn't
seem to propagate in some of the fields in gdb. In many cases, this will end
up crashing gdb (failing a thread_info=NULL gdbassert).

[Thread 803855580 (LWP 100241 Foo) exited]
error: Invalid selected thread.
thread.c:583: internal-error: set_running: Asser                  tion
`tp->state_ != THREAD_EXITED' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) [answered                   Y; input
not from terminal]
thread.c:583: internal-error: set_running: Asser                  tion
`tp->state_ != THREAD_EXITED' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) [answered Y;                   input not
from terminal]

Is this a symptom of FreeBSD and some libraries? Or is this a gross gdb
issue?

-- 
View this message in context: http://old.nabble.com/Thread-exit-error-%3A-gdb7.2-in-FreeBSD-%28built-from-ports%29-tp32463912p32463912.html
Sent from the Sourceware - gdb list mailing list archive at Nabble.com.

^ permalink raw reply	[flat|nested] 10+ messages in thread
end of thread, other threads:[~2011-09-23 19:31 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-09-22 22:30 Thread exit error : gdb7.2 in FreeBSD (built from ports) John Schumacher
  -- 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

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).