From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 78764 invoked by alias); 25 Mar 2019 22:20:51 -0000 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 Received: (qmail 78298 invoked by uid 89); 25 Mar 2019 22:20:50 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,KAM_NUMSUBJECT,SPF_HELO_PASS autolearn=no version=3.3.1 spammy=encrypted, 7628, sergio, H*f:sk:87r2azk X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 25 Mar 2019 22:20:49 +0000 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 17184C057F9A; Mon, 25 Mar 2019 22:20:48 +0000 (UTC) Received: from localhost (unused-10-15-17-196.yyz.redhat.com [10.15.17.196]) by smtp.corp.redhat.com (Postfix) with ESMTP id BB6DA842B6; Mon, 25 Mar 2019 22:20:47 +0000 (UTC) From: Sergio Durigan Junior To: Tom Tromey Cc: Pedro Alves , Tom Tromey , gdb-patches@sourceware.org Subject: Re: [PATCH] Merge handle_inferior_event and handle_inferior_event_1 References: <20190320140846.13031-1-tromey@adacore.com> <87r2azkhmq.fsf@redhat.com> <87mulnkcab.fsf@redhat.com> <87a7hjj7aw.fsf@tromey.com> <87ef6uj408.fsf@tromey.com> Date: Mon, 25 Mar 2019 22:20:00 -0000 In-Reply-To: <87ef6uj408.fsf@tromey.com> (Tom Tromey's message of "Mon, 25 Mar 2019 10:46:47 -0600") Message-ID: <87mulia94w.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2019-03/txt/msg00571.txt.bz2 On Monday, March 25 2019, Tom Tromey wrote: >>>>>> "Pedro" == Pedro Alves writes: > > Pedro> So it looks like your patch made it so that the value in question > Pedro> avoids the crash because the value in question is no longer in the > Pedro> all_values vector by the time gdb is tearing down? > > Makes sense. Thanks Pedro for the explanation. Yeah, after investigating it became clear to me that the patch fixes (or "fixes") the bug by destroying the value instances before we exit GDB. What's interesting is the fact that I cannot seem to reproduce easily. For example, if you print anything other than an xmethod, and then you print an xmethod, and then exit GDB, everything works correctly. For that reason, I'm still not able to write a testcase for it, because our testing infrastructure prints some stuff as a preparation for the test. > Pedro> Open questions then would be: > > Pedro> - what was the exception in question that was thrown from > Pedro> within handle_inferior_event_1? (And if there was > Pedro> no exception, then the theory above is incorrect.) > > Pedro> - why don't non-temporary xmethod values put in the value history > Pedro> cause a similar crash at tear down time? > > Also, if a crash can occur during value destruction like this, then I > think it must indicate a bug somewhere else, like invalid reference > counting somewhere. That's a good point, yeah. I can try investigating more. Having said that, I think the patch is simple enough to be safely backportable to 8.3, and it doesn't really break anything (in fact, as Pedro mentioned, it makes things more correct, because now we're sure that we will destroy the objects if an exception is thrown), so IMHO there's no downside to it. WDYT? Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/