From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.61]) by sourceware.org (Postfix) with ESMTP id 1C4C5384B0C1 for ; Wed, 15 Apr 2020 15:33:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1C4C5384B0C1 Received: from mail-ed1-f72.google.com (mail-ed1-f72.google.com [209.85.208.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-20-Oge8OuEcNnSr0KlZRFe13A-1; Wed, 15 Apr 2020 11:33:15 -0400 X-MC-Unique: Oge8OuEcNnSr0KlZRFe13A-1 Received: by mail-ed1-f72.google.com with SMTP id ba30so3268729edb.6 for ; Wed, 15 Apr 2020 08:33:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=icEywJ2XKJssbGJlolKyxgjo5jpMrG4ws8ksDLJ6E5U=; b=R08K9V8DiO5y9+OD0W9DFApV+1A2wxh0WX+lCfWo2I4+G/I+o5P0K74mkgbv8FhFG2 9DbiaCzolEf4D9MGx8Ww53LveNJlo9yuslbpmL7EkOLwMBmyw7Ya2rXQ7NXOlz7iC4CN 2fRWYsXKNr3SCycLakyuDLrv23gs3H7p0Mp/tCsWOGuFyBNEoDFG+hytcFFSDJgp1kXg dEDTRUs4AJIIaNjm9v9PGlS6WKZcYNX6yRLtZGwFFvf/zm2mql/p7pJC/IVR91Jyj5XF 4OyuPbzk1fhHjP4vKFC+IOfp3DjYHFLds2t7K0MsoIrs+FgUovxGuXa/yswenXFI/FyC /RWA== X-Gm-Message-State: AGi0PuaKsA+XjTXGl8OrMhSfzXTjzsCc360dCv7M5tu+uoQIJfzYl4PL YUIlgIMk+RCsLO4sQvRidFK8aW4a5PMxRmooBYpp9SRh069fZggohzVBoCPqJD9h5+G6NtcXa5r k3mmO36riI1GJTINJwyumCQ== X-Received: by 2002:a17:906:4406:: with SMTP id x6mr3783996ejo.160.1586964793399; Wed, 15 Apr 2020 08:33:13 -0700 (PDT) X-Google-Smtp-Source: APiQypL0FKuzWtJmQamQDmCXGGQFHBecuMIOqSPZwApNZ2FKY2ptcScehp4Dzq/MTIJGVy8uu6DgZw== X-Received: by 2002:a17:906:4406:: with SMTP id x6mr3783959ejo.160.1586964792967; Wed, 15 Apr 2020 08:33:12 -0700 (PDT) Received: from ?IPv6:2001:8a0:f909:7b00:56ee:75ff:fe8d:232b? ([2001:8a0:f909:7b00:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id i16sm1998211ejy.64.2020.04.15.08.33.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 15 Apr 2020 08:33:12 -0700 (PDT) Subject: Re: [PATCH 00/28] Decouple inferior_ptid/inferior_thread(); dup ptids in thread list (PR/25412) To: Simon Marchi , gdb-patches@sourceware.org References: <20200414175434.8047-1-palves@redhat.com> <89e862fa-678d-7b64-6776-c9179fce6ba6@simark.ca> From: Pedro Alves Message-ID: <0b87f757-dfa8-6737-1e28-f6534d44bf11@redhat.com> Date: Wed, 15 Apr 2020 16:33:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <89e862fa-678d-7b64-6776-c9179fce6ba6@simark.ca> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-11.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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: Wed, 15 Apr 2020 15:33:18 -0000 On 4/15/20 3:46 PM, Simon Marchi wrote: > On 2020-04-14 1:54 p.m., Pedro Alves via Gdb-patches wrote: >> In PR/25412, Simon noticed that after the multi-target series, the >> tid-reuse.exp testcase manages to create a duplicate thread in the >> thread list. Or rather, two threads with the same PTID. >> >> This in turn exposes a design problem in GDB. The inferior_thread() >> function looks up the current thread based on inferior_ptid: >> >> struct thread_info* >> inferior_thread (void) >> { >> struct thread_info *tp = find_thread_ptid (current_inferior (), inferior_ptid); >> gdb_assert (tp); >> return tp; >> } >> >> But if there can be more than one thread in the thread list with the >> same ptid_t, inferior_thread() may well return the wrong thread. > > I don't quite understand this part of the explanation. Thread lists are > per-inferior, and an inferior is specific to one target, and ptids are > unique per-target. So it's not possible at the moment (or at least not > expected) to have two threads with the same ptid in one specific list. The tid-reuse.exp testcase is about: # Test running a program that spawns enough threads that the tid of an # exited thread is reused. GDB should not crash when this happens. I.e., the testcase spawns enough short-lived threads that we end up in add_thread_silent adding a new thread with the same ptid as a preexisting thread, because the kernel tids eventually wrap around. In this scenario, you know the preexisting thread with that ptid must be gone, since otherwise the kernel would not be reusing the thread id. But if that thread that is gone was the currently selected thread, or somewhere throughout gdb something holds a reference to it, then we can't delete that exiting thread immediately. That's how you end up with more than one thread with the same ptid in the thread list. Only one of those threads will be live, all other "dups" will be exited threads. So given that currently inferior_thread() does a look up by ptid, it can happen that GDB meant to have the live thread selected temporarily, say, but inferior_thread() returns the exited thread. Like, this could fail: switch_to_thread (exited_thread); { scoped_restore_current_thread restore_thread; switch_to_thread (live_thread); gdb_assert (inferior_thread () == live_thread); } Note this happens with a single inferior. Thanks, Pedro Alves