From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 72589 invoked by alias); 25 Mar 2019 16:34:50 -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 72246 invoked by uid 89); 25 Mar 2019 16:34:49 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1 spammy=18th, fedora, Fedora, H*f:sk:87mulnk X-HELO: mail-wr1-f66.google.com Received: from mail-wr1-f66.google.com (HELO mail-wr1-f66.google.com) (209.85.221.66) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 25 Mar 2019 16:34:48 +0000 Received: by mail-wr1-f66.google.com with SMTP id r4so3252191wrq.8 for ; Mon, 25 Mar 2019 09:34:47 -0700 (PDT) Return-Path: Received: from ?IPv6:2001:8a0:f913:f700:56ee:75ff:fe8d:232b? ([2001:8a0:f913:f700:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id 66sm303763wmd.3.2019.03.25.09.34.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Mar 2019 09:34:45 -0700 (PDT) Subject: Re: [PATCH] Merge handle_inferior_event and handle_inferior_event_1 To: Tom Tromey , Sergio Durigan Junior References: <20190320140846.13031-1-tromey@adacore.com> <87r2azkhmq.fsf@redhat.com> <87mulnkcab.fsf@redhat.com> <87a7hjj7aw.fsf@tromey.com> Cc: Tom Tromey , gdb-patches@sourceware.org From: Pedro Alves Message-ID: Date: Mon, 25 Mar 2019 16:34:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <87a7hjj7aw.fsf@tromey.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-03/txt/msg00548.txt.bz2 On 03/25/2019 03:35 PM, Tom Tromey wrote: >>>>>> ">" == Sergio Durigan Junior writes: > >>> A few days ago (March 18th) a user reported a bug against Fedora GDB: >>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=1690120 >>> >>> And, after hours and hours investigating this, I found that your commit >>> actually fixes it. Not sure if it was intended or not, but what a >>> coincidence... > > I am curious to know how this change could fix this bug. > That seems mysterious to me. There's one behavior change the patch makes, which is that before the patch, if handle_inferior_event_1 threw an error, value_free_to_mark would not be called. After the patch, it's always called, from scoped_value_mark's dtor. >From the backtrace in the bug report, we see that the crash happens late during teardown, destroying an xmethod value in the global "all_values" vector: ... #13 std::vector, std::allocator > >::~vector (this=0x559d15b24a10 , __in_chrg=) at /usr/include/c++/9/bits/stl_vector.h:677 No locals. #14 0x00007f92a8fe0700 in __run_exit_handlers () from /lib64/libc.so.6 No symbol table info available. #15 0x00007f92a8fe0840 in exit () from /lib64/libc.so.6 No symbol table info available. ... So it looks like your patch made it so that the value in question avoids the crash because the value in question is no longer in the all_values vector by the time gdb is tearing down? Open questions then would be: - what was the exception in question that was thrown from within handle_inferior_event_1? (And if there was no exception, then the theory above is incorrect.) - why don't non-temporary xmethod values put in the value history cause a similar crash at tear down time? >>> Of course, something I'd also like to ask is: do you think this change >>> is trivial enough to be included in the 8.3 release? I'd like to see it >>> happen. I can create a bug if needed. > > I would have thought so but the fact that it causes this behavior makes > me worry a bit. Maybe that's backward! Thanks, Pedro Alves