From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21515 invoked by alias); 20 Jun 2013 15:37:23 -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 21505 invoked by uid 89); 20 Jun 2013 15:37:23 -0000 X-Spam-SWARE-Status: No, score=-8.1 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Thu, 20 Jun 2013 15:37:22 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r5KFbI37032598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Jun 2013 11:37:18 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r5KFbGCx019941; Thu, 20 Jun 2013 11:37:17 -0400 Message-ID: <51C321AC.3030506@redhat.com> Date: Thu, 20 Jun 2013 16:06:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: Joel Brobecker CC: Jan Kratochvil , gdb-patches@sourceware.org, Markus Metzger Subject: Re: [patch] Fix cleanup in finish_command References: <20130619211444.GA29379@host2.jankratochvil.net> <20130620143118.GA11929@host2.jankratochvil.net> <20130620151806.GD4724@adacore.com> In-Reply-To: <20130620151806.GD4724@adacore.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-06/txt/msg00544.txt.bz2 On 06/20/2013 04:18 PM, Joel Brobecker wrote: >> BTW I have found the crash happens even with this patch, I haven't found the >> real cause yet. > > Interesting, as I couldn't understand the relationship between > the backtrace and the patch... You might also be in a situation > similar to what I faced on Darwin: a correct cleanup fix triggering > a latent bug; In that situation I found it useful to first git-bisect > to narrow down the commit that caused the change of behavior, and > then finish the bug off with valgrind's help. Seems to be that GDB got a SIGHUP while within proceed. That causes a "quit", which kills the inferior, and cancels it's threads' continuations, which deletes the finish breakpoint. >From the patch, I take it the cleanup that is supposed to delete that same finish breakpoint on error somehow ran before that, so that the end result is that GDB ended up trashed for trying to delete the same breakpoint twice? The discard_cleanups is after proceed because proceed may error too, with e.g., a QUIT, though other regular errors may happen. I think fixing this needs a bit more work. On error, the continuations are left stale in the thread (try hacking an error call just before proceed, after installing the continuation), which is wrong as it'll cause problems for the next execution command... I think we need to move the discard_cleanups above proceed, but, also make sure the continuations are cancelled on error (IOW, cancel the whole command on error). Maybe install a new cleanup while `proceed' is running, that runs: do_all_intermediate_continuations (1); do_all_continuations (1); (See inferior_event_handler.) -- Pedro Alves