From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20570 invoked by alias); 22 Sep 2011 16:34:44 -0000 Received: (qmail 20332 invoked by uid 22791); 22 Sep 2011 16:34:42 -0000 X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,BAYES_00,DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED,RP_MATCHES_RCVD,TW_TP,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: sourceware.org Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 22 Sep 2011 16:34:28 +0000 Received: from isper.nabble.com ([192.168.236.156]) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1R6mEF-0006OU-ME for gdb@sourceware.org; Thu, 22 Sep 2011 09:34:27 -0700 Message-ID: <32503830.post@talk.nabble.com> Date: Thu, 22 Sep 2011 16:34:00 -0000 From: Jusctsch To: gdb@sourceware.org Subject: Re: Thread exit error : gdb7.2 in FreeBSD (built from ports) In-Reply-To: <32503829.post@talk.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <32463912.post@talk.nabble.com> <201109141604.02961.pedro@codesourcery.com> <32465344.post@talk.nabble.com> <201109141859.20945.pedro@codesourcery.com> <32503829.post@talk.nabble.com> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2011-09/txt/msg00095.txt.bz2 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.