From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10921 invoked by alias); 9 Sep 2009 03:35:01 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 10844 invoked by uid 22791); 9 Sep 2009 03:35:00 -0000 X-SWARE-Spam-Status: No, hits=-3.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org To: archer@sourceware.org From: Andrew Sutherland Subject: [python] python-inferior add_inferior_object tries to access thread info before it exists with remote target (VMware remote stub) Date: Wed, 09 Sep 2009 03:35:00 -0000 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20090908 Shredder/3.0b4pre X-SW-Source: 2009-q3/txt/msg00188.txt.bz2 Using the python branch tip, attempting to connect to a VMware (Workstation 6.5.x) replay remote stub, I get a "thread.c:581: internal-error: is_thread_state: Assertion `tp' failed." assertion. I presume this is a unique problem because the stub refuses the "Hc-1" command with "E00" which means there are no magic_null_ptid protections in place. So gdb asks what the current thread is, and gets an answer. In the process of creating the inferior via remote_add_inferior (and before it gets to call add_thread_silent), things go off the rails when the python add_inferior_object notification calls get_current_arch in: cleanup = ensure_python_env (get_current_arch (), current_language); The communication leading up to this is: +$qC#b4 +$QC1#c5 +$qAttached#8f +$#00 + The death stack trace is: #5 0x080991d6 in internal_error (file=0x830c8a8 "thread.c", line=581, string=0x82cfcd2 "%s: Assertion `%s' failed.") at utils.c:1003 #6 0x08171f75 in is_thread_state (ptid=..., state=THREAD_EXITED) at thread.c:581 #7 0x08171fbb in is_exited (ptid=...) at thread.c:594 #8 0x0809f12f in has_stack_frames () at frame.c:1113 #9 0x0818758b in get_current_arch () at arch-utils.c:748 #10 0x08107c9b in add_inferior_object (pid=42000) at .././gdb/python/python-inferior.c:107 #11 0x080931af in generic_observer_notify (subject=, args=0xbfeff6d4) at observer.c:166 #12 0x080935a8 in observer_notify_new_inferior (pid=42000) at observer.inc:833 #13 0x080a4f1d in add_inferior_silent (pid=42000) at inferior.c:88 #14 0x080a4f47 in add_inferior (pid=42000) at inferior.c:96 #15 0x080d33bd in remote_add_inferior (pid=42000, attached=0) at remote.c:1181 #16 0x080db0c0 in remote_start_remote (uiout=0x84a4470, opaque=0xbfeff874) at remote.c:2707 #17 0x08174b4a in catch_exception (uiout=0x84a4470, func=0x80dad00 , func_args=0xbfeff874, mask=6) at exceptions.c:462 #18 0x080d6574 in remote_open_1 (name=, from_tty=1, target=0x83b2a40, extended_p=0) at remote.c:3333 My local fix is to cause has_stack_frames to treat a null thread_info the same as not having an inferior: index 67e0607..8698563 100644 --- a/gdb/frame.c +++ b/gdb/frame.c @@ -1106,7 +1106,8 @@ has_stack_frames (void) return 0; /* No current inferior, no frame. */ - if (ptid_equal (inferior_ptid, null_ptid)) + if (ptid_equal (inferior_ptid, null_ptid) || + !find_thread_ptid(inferior_ptid)) return 0; /* Don't try to read from a dead thread. */ Please let me know what the next step, if any, I should perform in order to get some form of fix in the tree. Thanks, Andrew