From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10611 invoked by alias); 15 Jun 2010 15:24:06 -0000 Received: (qmail 10600 invoked by uid 22791); 15 Jun 2010 15:24:05 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 15 Jun 2010 15:24:01 +0000 Received: (qmail 32475 invoked from network); 15 Jun 2010 15:24:00 -0000 Received: from unknown (HELO orlando.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 15 Jun 2010 15:24:00 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [python][patch] Inferior and Thread information support. Date: Tue, 15 Jun 2010 15:24:00 -0000 User-Agent: KMail/1.13.2 (Linux/2.6.32-22-generic; KDE/4.4.2; x86_64; ; ) Cc: Phil Muldoon , tromey@redhat.com References: <4BFA6E82.3070704@redhat.com> <4C1623C1.6090205@redhat.com> In-Reply-To: <4C1623C1.6090205@redhat.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201006151623.55766.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-06/txt/msg00337.txt.bz2 On Monday 14 June 2010 13:42:41, Phil Muldoon wrote: > On 06/10/2010 07:40 PM, Tom Tromey wrote: > >>>>>> "Phil" == Phil Muldoon writes: > > > > Phil> + THPY_REQUIRE_VALID (thread_obj); > > Phil> + > > Phil> + cleanup = make_cleanup_restore_current_thread (); > > Phil> + > > Phil> + TRY_CATCH (except, RETURN_MASK_ALL) > > Phil> + { > > Phil> + switch_to_thread (thread_obj->thread->ptid); > > Phil> + > > Phil> + frame = get_current_frame (); > > Phil> + frame_obj = frame_info_to_frame_object (frame); > > Phil> + } > > Phil> + GDB_PY_HANDLE_EXCEPTION (except); > > > > I am really not sure about this. > > > > Doesn't switch_to_thread reset the frame cache? > > Meaning that the returned frame_obj will immediately be invalid? > > > > You would have to try this with a multi-threaded program, where you are > > stopped in thread A but then request a frame in thread B. > > I'll investigate this further. I had concerns about this (I think we > chatted a little about this on irc way back when). I'll write an > inferior test and see. Maybe Pedro or someone else in that area knows > a little more. Tom is correct. You'll not see a problem with single-thread apps because switch_to_thread does an early return before invalidating the frame cache when the thread you're switching to is already current. In short, don't ever store a frame_info pointer like this. Instead, if you need to record the frame somewhere, store a frame_id. (I haven't really looked at the patch and the use case, just commenting from the what's quoted above) -- Pedro Alves