From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id ED82A3858D20 for ; Thu, 2 May 2024 18:05:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org ED82A3858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org ED82A3858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714673144; cv=none; b=Cvgb3w4GIg53vSGfJ6q9F8WAND/NzILm2Md/IxJScq5Q5oUJOJImkayabljG16g4nDf0obGDn2BzZ9w0fsKrfFUuXoF8kP1AMoxoE5YuZUh6FLWkBAkxctM0MnSEbh8mtuIMjxTY0df/de7rctd+DDAFV5pPwcuNMeaCGdvTZNk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714673144; c=relaxed/simple; bh=A/ucCj6vYFC/REMjjG0gYZqpj4T32q8XTfbArcWDAJU=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=MKWEuIlEBIbK6WM8Haps3Xcc83/6oTEcPFi7e3BYfyurEcY/WDtmyTk63xdGI2oQ1DAJAxH9g7kaTQi/DO/ZyZcMUe/HqW6FMQBngE/5lIXWUOf2EO9guwZePW8tJa8gzQHC4MikwxTVdS4cV8cA7y7evvU6WGCN3xQn//YwsL8= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1714673142; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=FYAt10BfARos7l3GbutBFZsUYadaQcsU4pT7/aGDTe0=; b=IyMb8m7QuKTB2ZQs0oK/0PZMF7mFDNynZ+Vieptzs8/TYm3GCQSYYgmEtt2+Y1EukLRPCw sFaCTa1WBuTcVNR6LJbYFZ1T89yinMI3dfG+fXEuRgZbMw9Ke0hXZ8G6A9JpkgzDNoFQq2 JDjTY1bqOnz6XA0XAi4wuaGkYgs1GuA= Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-480-NUTou0-kMrOOl4JPvUZP-g-1; Thu, 02 May 2024 14:05:41 -0400 X-MC-Unique: NUTou0-kMrOOl4JPvUZP-g-1 Received: by mail-qk1-f199.google.com with SMTP id af79cd13be357-7907346a0fdso465811485a.0 for ; Thu, 02 May 2024 11:05:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714673140; x=1715277940; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=FYAt10BfARos7l3GbutBFZsUYadaQcsU4pT7/aGDTe0=; b=bZMpie0DVn3ZYtE5GCezWWK2msUKfNZKWWU9LXRgMEys0QxJ+zRmOBHB0DCLqfKx+i RfCMXdYk6KRwhDttnDNvqaFpXhsid/JrUnVyhBspwDGqnpl9FwLmbN7Wv3B1Rs9KqR89 HpB3JKBrN/xsPOLV2lkAjlA/IpJcCuc7QN5l5pY1nNu1mUDDG8tIamUokUhh4mWmchWi fCit2K4zPUekUPhJccvB1jUxxd1+c1zEwYbgntT2EEKl+O9pUl289JEMMJunwfi+VoF+ qvV14yTbKuGa4rkVeNXM44fv2PQR18Yco+cCdGitur+wineL5anj9SCb3QnBR8+kocao GLpw== X-Gm-Message-State: AOJu0YxQV6nfGpLmJcCwfuCUWPvGaSsSchdNygEaAkyomWa0GmhadCs7 dayQ6d+IzyX8AKuENdFaIsXifQdsR/872Uxzcpuxq5rbSEjq9crZX36MyaMo4329LrMlxN8aQhB PXRzgg+LDD5N4NcYq8jueQDvC+tHFq82kwpyXY3E0sQUEr2GVusJ3QSdWt+VAASo= X-Received: by 2002:a05:620a:5236:b0:790:9817:309d with SMTP id dc54-20020a05620a523600b007909817309dmr909468qkb.9.1714673140258; Thu, 02 May 2024 11:05:40 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGDYudljyMeKBkuehnyZccGmMfpfPnRGtXCSowjzaEw+ePbYBLZZ+B5VixU49H3blEtuc2Wnw== X-Received: by 2002:a05:620a:5236:b0:790:9817:309d with SMTP id dc54-20020a05620a523600b007909817309dmr909430qkb.9.1714673139858; Thu, 02 May 2024 11:05:39 -0700 (PDT) Received: from [192.168.1.130] (130-44-146-16.s12558.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [130.44.146.16]) by smtp.gmail.com with ESMTPSA id vz8-20020a05620a494800b0078ef8c994bcsm543154qkn.105.2024.05.02.11.05.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 02 May 2024 11:05:39 -0700 (PDT) Message-ID: <09143a58-de03-4ba6-8996-38303a299c69@redhat.com> Date: Thu, 2 May 2024 14:05:38 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] c++/modules: Fix dangling pointer with imported_temploid_friends To: Nathaniel Shead , Patrick Palka Cc: gcc-patches@gcc.gnu.org, Nathan Sidwell References: <6631c581.170a0220.3b821.1e9d@mx.google.com> <66324e95.170a0220.20975.b0cb@mx.google.com> <6632edc2.170a0220.9abdd.00d3@mx.google.com> From: Jason Merrill In-Reply-To: <6632edc2.170a0220.9abdd.00d3@mx.google.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-11.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,RCVD_IN_SORBS_WEB,SPF_HELO_NONE,SPF_NONE,TXREP,URIBL_BLACK autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 5/1/24 21:34, Nathaniel Shead wrote: > On Thu, May 02, 2024 at 12:15:44AM +1000, Nathaniel Shead wrote: >> On Wed, May 01, 2024 at 09:57:38AM -0400, Patrick Palka wrote: >>> >>> On Wed, 1 May 2024, Nathaniel Shead wrote: >>> >>>> Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk (and >>>> later 14.2)? I don't think making it a GTY root is necessary but I felt >>>> perhaps better to be safe than sorry. >>>> >>>> Potentially another approach would be to use DECL_UID instead like how >>>> entity_map does; would that be preferable? >>>> >>>> -- >8 -- >>>> >>>> I got notified by Linaro CI and by checking testresults that there seems >>>> to be some occasional failures in tpl-friend-4_b.C on some architectures >>>> and standards modes since r15-59-gb5f6a56940e708. I haven't been able >>>> to reproduce but looking at the backtrace I suspect the issue is that >>>> we're adding to the 'imported_temploid_friend' map a decl that is >>>> ultimately discarded, which then has its address reused by a later decl >>>> causing a failure in the assert in 'set_originating_module'. >>>> >>>> This patch attempts to fix the issue in two ways: by ensuring that we >>>> only store the decl if we know it's a new decl (and hence won't be >>>> discarded), and by making the imported_temploid_friends map a GTY root >>>> so that even if the decl does get discarded later the address isn't >>>> reused. >>>> >>>> gcc/cp/ChangeLog: >>>> >>>> * module.cc (imported_temploid_friends): Mark GTY, and... >>>> (init_modules): ...allocate from GGC. >>>> (trees_in::decl_value): Only write to imported_temploid_friends >>>> for new decls. >>>> >>>> Signed-off-by: Nathaniel Shead >>>> --- >>>> gcc/cp/module.cc | 7 ++++--- >>>> 1 file changed, 4 insertions(+), 3 deletions(-) >>>> >>>> diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc >>>> index 5b8ff5bc483..37d38bb9654 100644 >>>> --- a/gcc/cp/module.cc >>>> +++ b/gcc/cp/module.cc >>>> @@ -2731,7 +2731,7 @@ static keyed_map_t *keyed_table; >>>> need to be attached to the same module as the temploid. This maps >>>> these decls to the temploid they are instantiated them, as there is >>>> no other easy way to get this information. */ >>>> -static hash_map *imported_temploid_friends; >>>> +static GTY(()) hash_map *imported_temploid_friends; >>>> >>>> /********************************************************************/ >>>> /* Tree streaming. The tree streaming is very specific to the tree >>>> @@ -8327,7 +8327,8 @@ trees_in::decl_value () >>>> if (TREE_CODE (inner) == FUNCTION_DECL >>>> || TREE_CODE (inner) == TYPE_DECL) >>>> if (tree owner = tree_node ()) >>>> - imported_temploid_friends->put (decl, owner); >>>> + if (is_new) >>>> + imported_temploid_friends->put (decl, owner); >>> >>> Hmm, I'm not seeing this code path getting reached for tpl-friend-4_b.C. >>> It seems we're instead adding to imported_temploid_friends from >>> propagate_defining_module, during tsubst_friend_function. >>> >>> What seems to be happening is that we we first tsubst_friend_function >>> 'foo' from TPL, and then we tsubst_friend_function 'foo' from DEF, >>> which ends up calling duplicate_decls, which ggc_frees this 'foo' >>> redeclaration that is still present in the imported_temploid_friends map. >>> >>> So I don't think marking imported_temploid_friends as a GC root would >>> help with this situation. If we want to keep imported_temploid_friends >>> as a tree -> tree map, I think we just need to ensure that a decl >>> is removed from the map upon getting ggc_free'd from e.g. duplicate_decls. Could we instead move the call to propagate_defining_module down a few lines, after the pushdecl? >>> But it seems simpler to use DECL_UID as the key instead, since those >>> never get reused even after the decl gets ggc_free'd IIUC. It still means garbage entries in the hash_map, which is undesirable even if it doesn't cause the same kind of breakage. Incidentally, decl_tree_map is preferable to hash_map when the key is always a decl. Jason