From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) by sourceware.org (Postfix) with ESMTPS id CC27B3858C74; Thu, 12 Jan 2023 18:25:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CC27B3858C74 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wm1-x336.google.com with SMTP id p3-20020a05600c1d8300b003d9ee5f125bso10726564wms.4; Thu, 12 Jan 2023 10:25:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=a/WIw5HWGWMei7c+/ndlwOm26YSdf6m84Y5EjpnuLow=; b=KWxVIadpLGZFfaqFXXZ+cfp8qVE23Dvam6A0sGNtgHaw6tVmcjyikeyx8GrgvAmDcz 9wQqFzTS/VHMEZX+xkF61xTrl2kYf3La9zR7LgTf7n6SmPi9XxW8caKZ4gCotzAdo0jI 9t9SfcGt3JIm4MKUIDyboyalEYco9FTKXR5MYR+F37hv/mPI/Y3d9NyFx0/rfmXdyMSL nR4t++E4wnq9MogZhHvmANhjK0c3ByvFlP1VjYJKAwljB7nrUSW6DBDzFf/4P3qk+24q w8chyrN9XSBOyyzmLtZlwCggzOilN61lN5fKCptIkgIxBaoSc0eAzfk/M5cUhhCJjW1Z mtug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=a/WIw5HWGWMei7c+/ndlwOm26YSdf6m84Y5EjpnuLow=; b=jJg9dYXzdYB01gFRA/A4efVgwWQnCaaU9KyLVsef7w8u87c27/6f5Q9uX7s+uN6+ws RgxDuK39EVipd7wVwwhXKI2aUNQ5IPfAIt6wzZXgzo/xw9FJT6St147tbXRuSniZnicX 29opLYWsn5Ux+Zl6VyfOXHup9gEbIGXVxo6X7J58QmQXXXMJM2v82ih0BVlO42tKp2mF TQm4Cqdh3puPTaz+wpF3HlEWhEEQZGveCjd8bW05OohWkfBVeP5IpANdnokIlAwKJ0z9 MpiLBETkwzVs/uYQwqJCRJ2ehDemCzVVtRd9nFSbvZRuOh4VkevHQt+ItaWRg80at8Yz c8nQ== X-Gm-Message-State: AFqh2koPqhQ3p8xWJ4nqvNX9e5hbgTLEX9AMwQlE3inrrkeQHicGKfNk Eik/Qm3OnpFDNrtjHM4ER/o= X-Google-Smtp-Source: AMrXdXujh7j6ZP9/2kvYkPK1B+Ny09jh61EMfzU0ZI1mb/tCzjV64QVtduDtobt0IbQ00a/6Tx8UHQ== X-Received: by 2002:a7b:ce87:0:b0:3d9:f37e:2acb with SMTP id q7-20020a7bce87000000b003d9f37e2acbmr11591869wmj.20.1673547915462; Thu, 12 Jan 2023 10:25:15 -0800 (PST) Received: from [10.37.2.113] ([109.190.253.11]) by smtp.googlemail.com with ESMTPSA id cl10-20020a5d5f0a000000b002423620d356sm17178921wrb.35.2023.01.12.10.25.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 Jan 2023 10:25:14 -0800 (PST) Message-ID: <6f88e8e7-6771-d344-beb4-1ca37d79dd5c@gmail.com> Date: Thu, 12 Jan 2023 19:25:02 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: libstdc++: Fix deadlock in debug iterator increment [PR108288] To: Jonathan Wakely Cc: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org References: <20230106115402.178926-1-jwakely@redhat.com> Content-Language: fr From: =?UTF-8?Q?Fran=c3=a7ois_Dumont?= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A,RCVD_IN_BARRACUDACENTRAL,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no 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 12/01/23 13:00, Jonathan Wakely wrote: > On Thu, 12 Jan 2023 at 05:52, François Dumont wrote: >> Small update for an obvious compilation issue and to review new test >> case that could have lead to an infinite loop if the increment issue was >> not detected. >> >> I also forgot to ask if there is more chance for the instantiation to be >> elided when it is implemented like in the _Safe_local_iterator: >> return { __cur, this->_M_sequence }; > No, that doesn't make any difference. > >> than in the _Safe_iterator: >> return _Safe_iterator(__cur, this->_M_sequence); >> >> In the case where the user code do not use it ? >> >> Fully tested now, ok to commit ? >> >> François >> >> On 11/01/23 07:03, François Dumont wrote: >>> Thanks for fixing this. >>> >>> Here is the extension of the fix to all post-increment/decrement >>> operators we have on _GLIBCXX_DEBUG iterator. > Thanks, I completely forgot we have other partial specializations, I > just fixed the one that showed a deadlock in the user's example! > >>> I prefer to restore somehow previous implementation to continue to >>> have _GLIBCXX_DEBUG post operators implemented in terms of normal post >>> operators. > Why? > > Implementing post-increment as: > > auto tmp = *this; > ++*this; > return tmp; > > is the idiomatic way to write it, and it works fine in this case. I > don't think it performs any more work than your version, does it? > Why not use the idiomatic form? > > Is it just so that post-inc of a debug iterator uses post-inc of the > underlying iterator? Why does that matter? > A little yes, but that's a minor reason that is just making me happy. Main reason is that this form could produce a __msg_init_copy_singular before the __msg_bad_inc. And moreover I plan to propose a patch later to skip any check in the call to _Safe_iterator(__cur, _M_sequence) as we already know that __cur is ok here like anywhere else in the lib. There will still be one in the constructor normally elided unless --no-elide-constructors but there is not much I can do about it.