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

[Jusctsch <schumjs at gmail dot com>]

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.