From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) by sourceware.org (Postfix) with ESMTPS id 26116385841D for ; Mon, 7 Mar 2022 20:27:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 26116385841D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wm1-f41.google.com with SMTP id m42-20020a05600c3b2a00b00382ab337e14so135637wms.3 for ; Mon, 07 Mar 2022 12:27:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=l+O/YoLCjdVK17BGAM1RS6GX3W/WjPb+S8x2SuqHVDU=; b=JSwdGjTzMrcO7RdqEwZR+DXNLqo/Y/4jskADWvkY0lKMzG4gHaVOjFXcTBnAHgiQ85 LbhbVbcOCFfv5kUQbh8xFStFQze6Pi2l3UG+vn2nESqFJsugMXe6tjaLtrHes0vp09Lb R0rCiKBEmKiGEPjdMH6b7s7ft4bxrRrirVFBJvU+eLzYdmH4oyY/ucrgTS0qw6H9eY74 bGGKTk0kiLjw+FEbb4Bh4ccmde9dsdxDSoG32Cea2PWL4cQk7AV5uRINfvlF0cEyNaRW fz09m2CRHL/BG29jarL7cSUlI+6MIzuNr2GkFYzg/gB34fAlJ3nwWTC0OhUwO7d2xrad y+kw== X-Gm-Message-State: AOAM531ho1fkYqpM9tJVP1kttfAFRCB6IdgVv/thFS5cXYWH4EWJytOS 0LBZPJC9MhbCJr+gcLj2mBz47w3Kj9k= X-Google-Smtp-Source: ABdhPJy/FPD09q/R9s0zGVteEeWFXlqJ6REQ/EAanysLx63fbpJvOAjQ3Ck1rWhaamNKMkwg68ThSQ== X-Received: by 2002:a05:600c:1c28:b0:389:b614:68f2 with SMTP id j40-20020a05600c1c2800b00389b61468f2mr591048wms.142.1646684826115; Mon, 07 Mar 2022 12:27:06 -0800 (PST) Received: from ?IPV6:2001:8a0:f924:2600:209d:85e2:409e:8726? ([2001:8a0:f924:2600:209d:85e2:409e:8726]) by smtp.gmail.com with ESMTPSA id bg18-20020a05600c3c9200b0037c2ef07493sm422250wmb.3.2022.03.07.12.27.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Mar 2022 12:27:05 -0800 (PST) Message-ID: Date: Mon, 7 Mar 2022 20:27:03 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Subject: Re: [PATCH 07/11] Re-add zombie leader on exit, gdb/linux Content-Language: en-US To: Simon Marchi , gdb-patches@sourceware.org References: <20220303144020.3601082-1-pedro@palves.net> <20220303144020.3601082-8-pedro@palves.net> From: Pedro Alves In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2022 20:27:08 -0000 On 2022-03-07 20:08, Simon Marchi wrote: > On 2022-03-03 09:40, Pedro Alves wrote: >> @@ -2814,7 +2822,23 @@ linux_nat_filter_event (int lwpid, int status) >> /* Don't report an event for the exit of an LWP not in our >> list, i.e. not part of any inferior we're debugging. >> This can happen if we detach from a program we originally >> - forked and then it exits. */ >> + forked and then it exits. However, note that we may have >> + earlier deleted a leader of an inferior we're debugging, >> + in check_zombie_leaders. Re-add it back here if so. */ >> + for (inferior *inf : all_inferiors (linux_target)) >> + { >> + if (inf->pid == lwpid) >> + { >> + linux_nat_debug_printf >> + ("Re-adding thread group leader LWP %d after exit.", >> + lwpid); >> + >> + lp = add_lwp (ptid_t (lwpid, lwpid)); >> + lp->resumed = 1; >> + add_thread (linux_target, lp->ptid); >> + break; >> + } >> + } > > Should we do this only if WIFEXITED? We don't expect to get any other > event from a deleted leader, so it's more to be safe in case there is a > kernel bug or something that would make us see something else. > Hmm, can you clarify? We're doing this for both WIFEXITED and WIFSIGNALED. The WIFSTOPPED case doesn't get here, it's handled in the if/then branch. I do think we need to do this for exits due to WIFSIGNALED just the same. Do you think otherwise? > Otherwise, LGTM. > > Simon >