From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27780 invoked by alias); 22 Sep 2011 15:49:49 -0000 Received: (qmail 27770 invoked by uid 22791); 22 Sep 2011 15:49:48 -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,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 15:49:30 +0000 Received: from isper.nabble.com ([192.168.236.156]) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1R6lWj-0001MO-V0 for gdb@sourceware.org; Thu, 22 Sep 2011 08:49:29 -0700 Message-ID: <32503829.post@talk.nabble.com> Date: Thu, 22 Sep 2011 15:49:00 -0000 From: Jusctsch To: gdb@sourceware.org Subject: Re: Thread exit error : gdb7.2 in FreeBSD (built from ports) In-Reply-To: <201109141859.20945.pedro@codesourcery.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> 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/msg00094.txt.bz2 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 , 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 , 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 , 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.