From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20967 invoked by alias); 14 Feb 2012 14:19:12 -0000 Received: (qmail 20954 invoked by uid 22791); 14 Feb 2012 14:19:11 -0000 X-SWARE-Spam-Status: No, hits=-6.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 14 Feb 2012 14:18:59 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q1EEIx65025034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 14 Feb 2012 09:18:59 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q1EEIvMj027651; Tue, 14 Feb 2012 09:18:58 -0500 Message-ID: <4F3A6D51.5010904@redhat.com> Date: Tue, 14 Feb 2012 14:19:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120131 Thunderbird/10.0 MIME-Version: 1.0 To: Tom Tromey , Jan Kratochvil , gdb-patches@sourceware.org Subject: Re: RFC: fix crash when inferior exits during "continue" References: <20120210144040.GA28038@host2.jankratochvil.net> <87ty2ya1ys.fsf@fleche.redhat.com> <20120214134417.GA6730@redhat.com> In-Reply-To: <20120214134417.GA6730@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: 2012-02/txt/msg00263.txt.bz2 On 02/14/2012 01:44 PM, Gary Benson wrote: > Tom Tromey wrote: >>>>>>> "Jan" == Jan Kratochvil writes: >> >> Jan> Maybe during make_cleanup_restore_current_thread temporarily >> Jan> remember + clear inferior-> removable instead. >> >> I hadn't considered this, but it is an interesting idea. >> >> It would have the maybe odd effect of leaving the dead inferior >> around as long as it was selected. Maybe this is even the clearest >> thing to do; I am not sure. >> >> Do you (or anybody) have an opinion on which is better? > > I'm not especially familiar with this area of GDB, but I prefer the > idea of holding the selection on the dead inferior over arbitrarily > selecting another. I think the latter could be confusing. Yeah. We also don't randomly switch to another thread if the previous selected thread exits (and this is the reason we have "exited" threads). Otherwise, if the user is typing (gdb) some_command_that_applies_to_the_current_thread and the current thread disappears while the user is typing, the command ends up being applied to a random thread, which is not good. In this case, we need to step back a little. Why are we removing the inferior at all? The whole idea of inf->removable was that when you run, say, "make check" under gdb, and you follow all forks, you don't want to end up with 1000 inferiors loaded. So gdb marks inferiors/forks that appeared not by explicit user action as "removable". Those that are removable are pruned by prune_inferiors, roughly whenever we handle an event that gives the prompt to the user (at the end of normal_stop). But in this case, the user explicitly switched to a "removable" inferior, and then resumed (inferior 2; continue; ) So we may consider two things: - The inferior should no longer be "removable". The user has expressed interest in it. - Make make_cleanup_restore_current_thread "lock" the current inferior, so it isn't removed even if it is "removable". We do something similar for threads -- That's the whole reason for thread_info->refcount. (This is also Jan's suggestion.) -- Pedro Alves