Re: Thread exit error : gdb7.2 in FreeBSD (built from ports)

Re: Thread exit error : gdb7.2 in FreeBSD (built from ports)

[John Schumacher]

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

Re: Thread exit error : gdb7.2 in FreeBSD (built from ports)

[John Schumacher]

On Thu, 2011-09-22 at 17:06 -0500, John Schumacher wrote:
> 
> 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
> 
> 

I have questions about the following areas of code within fbsd-threads.c

static ptid_t
fbsd_thread_wait (struct target_ops *ops,
		  ptid_t ptid, struct target_waitstatus *ourstatus, int options)
{
....
      if (ourstatus->value.sig == TARGET_SIGNAL_TRAP)
        check_event(ret);
      /* this is a hack, if an event won't cause gdb to stop, for
example,
         SIGARLM, gdb resumes the process immediatly without setting
         inferior_ptid to the new thread returned here, this is a bug
         because inferior_ptid may already not exist there, and passing
         a none existing thread to fbsd_thread_resume causes error. */
      if (!fbsd_thread_alive (ops, inferior_ptid))
        {
          delete_thread (inferior_ptid);
          inferior_ptid = ret;
        }
    }

  return (ret);
}

Don't we already notify gdb of this through handle_inferior_event? Why
should fbsd-threads.c do this on its own? 
When debugging I saw the following:  we remove the thread here, but
later then an execution_control_state is still created for
handle_inferior_event for the exiting lwp ( or thread, it's used
ambiguously in the case of 1:1 threading) with stop_func_name =
0x8018c13c5 "_thread_bp_death" for the exiting thread. As the thread
state is '_exiting', we will then get hosed later when we handle this as
it checks get_current_frame() (which has an error if the thread state ==
exiting) and forces the user to have to switch to a different thread.

When this delete is commented out, threads are still being properly
removed and no error()'s are occurring. Can you shed any light on the
condition that it is talking about?

(Hopefully this message will pass through without modification, I'm
using plain-text)

Re: Thread exit error : gdb7.2 in FreeBSD (built from ports)

[Pedro Alves]

On Thursday 22 September 2011 17:34:27, Jusctsch wrote:
> At this point, our inferior_ptid is the thread we planned on deleting, so we
> don't delete it and flag it as exited. It does do some cleanup however, and
> dips back into fbsd-threads.c a few times... Let's continue.
> 
> GDB on Application
> 
> infrun: target_wait (-1, status) =
> infrun:   1461 [Thread 831ff4900 (LWP 100269 BMC Event Log m)],
> infrun:   status->kind = stopped, signal = SIGTRAP
> infrun: infwait_normal_state
> infrun: TARGET_WAITKIND_STOPPED
> infrun: stop_pc = 0x801b169c1
> 
> GDB on GDB
> 
> Breakpoint 5, get_current_frame () at frame.c:1177
> 1177       error (_("Invalid selected thread."));
> 
> (gdb)
> (gdb) p inferior_ptid
> $6 = {pid = 1461, lwp = 0, tid = 100269}
> (gdb)

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

Re: Thread exit error : gdb7.2 in FreeBSD (built from ports)

[Jusctsch]

Jusctsch wrote:
> 
> 
> Any thoughts? Is this the regular operation of gdb7.2? Maybe that
> tp->refcount field is never decremented to 0 (for the exiting thread for
> some reason). I will take a look at that and append my results, as well as
> running gdb under "set debug infrun 1".
> 
> 
I've got GDB running on GDB, and GDB running on my application

GDB on application
(running with set debug infrun 1)
infrun: context switch
infrun: Switching context from Thread 82b23c300 (LWP 100216 BMC SENSOR) to
Thread 831ff4900 (LWP 100269 BMC Event Log m)
infrun: BPSTAT_WHAT_SINGLE
infrun: no stepping, continue
infrun: resume (step=1, signal=0), trap_expected=1
infrun: prepare_to_wait

(Then on GDB on GDB)

Breakpoint 6, delete_thread_1 (ptid=..., silent=0) at thread.c:247
247       tpprev = NULL;

(gdb) bt
#0  delete_thread_1 (ptid=..., silent=0) at thread.c:247
#1  0x000000000054a5bc in delete_thread (ptid=...) at thread.c:296
#2  0x000000000047ceb3 in fbsd_thread_wait (ops=0x9ae980, ptid=...,
ourstatus=0x7fffffffe320, options=0)
    at fbsd-threads.c:778
#3  0x00000000005743d9 in target_wait (ptid=..., status=0x7fffffffe320,
options=0) at target.c:2219
#4  0x000000000053ad64 in wait_for_inferior (treat_exec_as_sigtrap=0) at
infrun.c:2529

continue...

GDB on GDB

Breakpoint 7, delete_thread_1 (ptid=..., silent=0) at thread.c:259
259       if (tp->refcount > 0
260       || ptid_equal (tp->ptid, inferior_ptid))

(gdb) p tp->refcount
$2 = 0
(gdb) p inferior_ptid
$3 = {pid = 1461, lwp = 0, tid = 100269}
(gdb)



At this point, our inferior_ptid is the thread we planned on deleting, so we
don't delete it and flag it as exited. It does do some cleanup however, and
dips back into fbsd-threads.c a few times... Let's continue.

GDB on Application

infrun: target_wait (-1, status) =
infrun:   1461 [Thread 831ff4900 (LWP 100269 BMC Event Log m)],
infrun:   status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x801b169c1

GDB on GDB

Breakpoint 5, get_current_frame () at frame.c:1177
1177       error (_("Invalid selected thread."));

(gdb)
(gdb) p inferior_ptid
$6 = {pid = 1461, lwp = 0, tid = 100269}
(gdb)


We still haven't moved off that ptid... 
I've traced back the different callers of delete_thread_1 and some head into
the FreeBSD land of fbsd-threads.c, but in this case, FreeBSD has done his
job and called that his thread was done, why should gdb expect another call
to that function- at the point in time when gdb choses not to have that
exiting thread as the inferior_ptid?
Should gdb switch inferior_ptid off an exiting thread, to either a NULL ptid
or other running ptid on thread deletion- to cover for the fact that
functions such as get_current_frame() require a non exited thread?

Is there anything else you want me to look at. I would find some value in a
fix, and would be willing to help. In the case of a real-time app, we
shouldn't break into the debugger unless we want to (for obvious reasons),
which this issue causes.
Thanks for your help!
-- 
View this message in context: http://old.nabble.com/Thread-exit-error-%3A-gdb7.2-in-FreeBSD-%28built-from-ports%29-tp32463912p32503830.html
Sent from the Sourceware - gdb list mailing list archive at Nabble.com.

Re: Thread exit error : gdb7.2 in FreeBSD (built from ports)

[Jusctsch]

Pedro Alves-10 wrote:
> 
> Please don't top post.
> 
> I understand that the whole program exited, and you're getting
> that error from withing get_current_frame, right?  Please give
> me the most detail as possible so that I don't have to try
> to guess things.
> 
> Why is GDB calling get_current_frame at all?  Please show the
> same but with "set debug infrun 1".  Sounds like a FreeBSD
> backend bug.
> 
> -- 
> Pedro Alves
> 
> 

The virgin code for gdb7.2, after FreeBSD patches, is currently running.

This issue occurs after a thread has exited, but the logic in
delete_thread_1 dictates that this if statement is fallen through:
thread.c:259-260
  if (tp->refcount > 0 || ptid_equal (tp->ptid, inferior_ptid))
In which we do not delete the internal bookkeeping of the thread, just flag
it as exited. It is my understanding that we then soon hit the
get_current_frame() for this exited thread (as the exited thread's ptid is
the inferior_ptid). This flag is hit in this code, which prompts the user to
switch threads.
This series of events is what I consider to be the bug.

This is the backtrace at the point of the error in get current_frame():
1777  	error (_("Invalid selected thread."));
(gdb) bt
#0  get_current_frame () at frame.c:1177
#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
#4  0x0000000000533760 in run_command_1 (args=0x801314084 "-d", from_tty=1,
tbreak_at_main=0) at infcmd.c:586
#5  0x00000000005337a0 in run_command (args=0x801314084 "-d", from_tty=1) at
infcmd.c:596
#6  0x00000000004aba04 in do_cfunc (c=0x8013a5700, args=0x801314084 "-d",
from_tty=1) at ./cli/cli-decode.c:67
#7  0x00000000004ae9c5 in cmd_func (cmd=0x8013a5700, args=0x801314084 "-d",
from_tty=1) at ./cli/cli-decode.c:1771
#8  0x000000000044d24c in execute_command (p=0x801314085 "d", from_tty=1) at
top.c:422
#9  0x000000000055533e in command_handler (command=0x801314080 "") at
event-top.c:498
#10 0x0000000000555922 in command_line_handler (rl=0x801313c68 "run -d") at
event-top.c:702
#11 0x0000000800ab7317 in rl_callback_read_char () from
/lib/libreadline.so.8
#12 0x00000000005549a1 in rl_callback_read_char_wrapper (client_data=0x0) at
event-top.c:178
#13 0x0000000000555209 in stdin_event_handler (error=0, client_data=0x0) at
event-top.c:433
#14 0x00000000005539ab in handle_file_event (data=...) at event-loop.c:817
#15 0x0000000000553022 in process_event () at event-loop.c:399
#16 0x000000000055310b in gdb_do_one_event (data=0x0) at event-loop.c:464
#17 0x000000000054d91f in catch_errors (func=0x553040 <gdb_do_one_event>,
func_args=0x0, errstring=0x741f23 "",
    mask=6) at exceptions.c:518
#18 0x00000000004c2144 in tui_command_loop (data=0x0) at
./tui/tui-interp.c:171
#19 0x000000000054e097 in current_interp_command_loop () at interps.c:291
#20 0x0000000000442d61 in captured_command_loop (data=0x0) at ./main.c:227
#21 0x000000000054d91f in catch_errors (func=0x442d50
<captured_command_loop>, func_args=0x0,
    errstring=0x7246a3 "", mask=6) at exceptions.c:518
#22 0x0000000000443c8a in captured_main (data=0x7fffffffea40) at
./main.c:925
#23 0x000000000054d91f in catch_errors (func=0x442da0 <captured_main>,
func_args=0x7fffffffea40,
    errstring=0x7246a3 "", mask=6) at exceptions.c:518
#24 0x0000000000443d11 in gdb_main (args=0x7fffffffea40) at ./main.c:934
#25 0x0000000000442a8e in main (argc=2, argv=0x7fffffffeab0) at gdb.c:43
(gdb)

Any thoughts? Is this the regular operation of gdb7.2? Maybe that
tp->refcount field is never decremented to 0 (for the exiting thread for
some reason). I will take a look at that and append my results, as well as
running gdb under "set debug infrun 1".

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

Re: Thread exit error : gdb7.2 in FreeBSD (built from ports)

[Pedro Alves]

Please don't top post.

On Wednesday 14 September 2011 18:12:06, Jusctsch wrote:
> 
> Sure, 
> I am running on FreeBSD, and they pull vanilla source and apply their
> patches to it. In addition, I had written a patch on my own which is
> removing an error check in get_current_frame on thread exit and running into
> an issue later on. I'm disregarding the fatal errors in the previous post
> and focusing on the "invalid thread" issue. With just the FreeBSD patches
> applied on gdb7.2, I boot up my application and see the following:
> 
> =thread-created,id="60",group-id="i1"
> ~"[New Thread 803855740 (LWP 100223)]\n"
> *running,thread-id="all"
> =thread-created,id="61",group-id="i1"
> ~"[New Thread 82b055500 (LWP 100235)]\n"
> *running,thread-id="all"
> ~"[Thread 82b055c00 (LWP 100221 FooTask) exited]\n"
> =thread-exited,id="58",group-id="i1"
> &"/tmp/.gdbinit:4: Error in sourced command file:\n"
> &"Invalid selected thread.\n"
> (gdb)

I understand that the whole program exited, and you're getting
that error from withing get_current_frame, right?  Please give
me the most detail as possible so that I don't have to try
to guess things.

Why is GDB calling get_current_frame at all?  Please show the
same but with "set debug infrun 1".  Sounds like a FreeBSD
backend bug.

-- 
Pedro Alves

Re: Thread exit error : gdb7.2 in FreeBSD (built from ports)

[Jusctsch]

Sure, 
I am running on FreeBSD, and they pull vanilla source and apply their
patches to it. In addition, I had written a patch on my own which is
removing an error check in get_current_frame on thread exit and running into
an issue later on. I'm disregarding the fatal errors in the previous post
and focusing on the "invalid thread" issue. With just the FreeBSD patches
applied on gdb7.2, I boot up my application and see the following:

=thread-created,id="60",group-id="i1"
~"[New Thread 803855740 (LWP 100223)]\n"
*running,thread-id="all"
=thread-created,id="61",group-id="i1"
~"[New Thread 82b055500 (LWP 100235)]\n"
*running,thread-id="all"
~"[Thread 82b055c00 (LWP 100221 FooTask) exited]\n"
=thread-exited,id="58",group-id="i1"
&"/tmp/.gdbinit:4: Error in sourced command file:\n"
&"Invalid selected thread.\n"
(gdb)
c
&"c\n"
~"Continuing.\n"
&"Cannot execute this command without a live selected thread.\n"
^error,msg="Cannot execute this command without a live selected thread."
(gdb)
c

Point being, I don't want to break into the debugger on an thread exit such
as this. This behavior is different than in 6.1.1 for FreeBSD.
See here:
http://lists.freebsd.org/pipermail/freebsd-ports-bugs/2011-May/211521.html

This is the bug.
Thanks!


Pedro Alves-10 wrote:
> 
> On Wednesday 14 September 2011 15:26:33, Jusctsch wrote:
>> 
>> 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? 
> 
> It's a gdb bug.
> 
> We'd need more context to understand the problem.
> 
> You can debug gdb with gdb, and put a breakpoint on
> `error' to catch that "error:", for example.  Where's
> that coming from?  Sounds like your port has local
> changes compared to the pristine FSF version?
> 
>> Or is this a gross gdb issue?
> 
> -- 
> Pedro Alves
> 
> 

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

Re: Thread exit error : gdb7.2 in FreeBSD (built from ports)

[Pedro Alves]

On Wednesday 14 September 2011 15:26:33, Jusctsch wrote:
> 
> 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? 

It's a gdb bug.

We'd need more context to understand the problem.

You can debug gdb with gdb, and put a breakpoint on
`error' to catch that "error:", for example.  Where's
that coming from?  Sounds like your port has local
changes compared to the pristine FSF version?

> Or is this a gross gdb issue?

-- 
Pedro Alves

Re: Thread exit error : gdb7.2 in FreeBSD (built from ports)

[Jusctsch]

I noticed this 'bad' behavior only in standard console gdb. The asserts do
not happen in gdb-mi mode.


Jusctsch wrote:
> 
> 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-tp32463912p32464063.html
Sent from the Sourceware - gdb list mailing list archive at Nabble.com.

Thread exit error : gdb7.2 in FreeBSD (built from ports)

[Jusctsch]

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.