From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) by sourceware.org (Postfix) with ESMTPS id 35FDC3858C78; Fri, 17 Feb 2023 11:03:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 35FDC3858C78 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-ed1-x52a.google.com with SMTP id co2so2339191edb.13; Fri, 17 Feb 2023 03:03:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=+HSHuHtkEzJCpR1/06MgQ0CS/LYyE/lQ/o0l+XPA5OU=; b=SJTE2DfktAvrmbtQ4xfu6K19x0Udbx5jvsw495BV0f5oQnrISGw9y3oe4IkMxJHXL1 hJntGG1atMR+ZqdhDFOJSDg7iIUhYcEwJ+ftvUhEQfCMXc51N1zhmdbilICfdnTXv7f1 62/QtPc0FsY6FbpqlrGoQmGMg7255WRjn4iu5GtWBf79fFL6LWutSA8IoMJxy2RuoS6t LALySHnYNyGpP/LHRtJ7WZZpZ3saFmmFTpJX/MLlTMHNOj747vdlRJZI6kmg+yobrxbn up+T3d7Kr+k3xlCNfzn66V+3h9GGuUN2zWhlfo6IZHqtljO1S7gp76S9XMID2cMDCRO+ zW7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=+HSHuHtkEzJCpR1/06MgQ0CS/LYyE/lQ/o0l+XPA5OU=; b=KvDd9x8fY6L3IgonSLhURm8PKi+l2HUvNZHQG7LG+zSWO2HAW7ChoRs5+SotMBQTJ5 YUsWetTIR/I1J//idfAHygGQPz+3ORy1L8VZRSCZcRoUWmv6Rp7U+4QHlNqWSscmBGQM Gv5IRl8Dx7QTduP1nyN4or1Q/qPOFJzIARFDsaSvtv+nXgzx0JO+WESZsYSp5Y6EMDpm 4nTw5OB7pKF4KRsiRwUK8lxAo4iJQLhYA5O5Djr9u64yODb6JTRDX7Ov3O8Xm8N7Wl+O tjrZgnDVR5M5RdWtLtXpmUldYHtVZFTWBL7d3Q7v0FkrNzHLmtz1QlKdX8xFAPl7+k56 YV+Q== X-Gm-Message-State: AO0yUKWdEH4CROTzwoFb/Uof5iKcLKNsrQEQfG7TbbJwEX6nYR3oGE8r 0ZFwlU9YchEEniSIXl7OJQZk0mfaO4MYMjeIe/QrccN4 X-Google-Smtp-Source: AK7set8ZAHMMdeWS5Wsb/e8Q8x7NLdtDP+EhqdS0DEXlycPfJcoGbBIBq09S1Ia78NVHhRKYrMffcOWQuN/+cYiZNw8= X-Received: by 2002:a17:906:fa92:b0:88d:f759:15b1 with SMTP id lt18-20020a170906fa9200b0088df75915b1mr279017ejb.13.1676631801938; Fri, 17 Feb 2023 03:03:21 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jonathan Wakely Date: Fri, 17 Feb 2023 11:03:09 +0000 Message-ID: Subject: Re: [PATCH] [libstdc++] ensure mutex_pool survives _Safe_sequence_base To: Alexandre Oliva Cc: gcc-patches , "libstdc++" Content-Type: multipart/alternative; boundary="000000000000f947d305f4e342cc" X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP 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: --000000000000f947d305f4e342cc Content-Type: text/plain; charset="UTF-8" On Fri, 17 Feb 2023, 08:02 Alexandre Oliva via Libstdc++, < libstdc++@gcc.gnu.org> wrote: > On Feb 17, 2023, Alexandre Oliva wrote: > > > On vxworks, after destroying the semaphore used to implement a mutex, > > __gthread_mutex_lock fails and __gnu_cxx::__mutex::lock calls > > __throw_concurrence_lock_error. Nothing ensures the mutex_pool > > mutexes survive init-once objects containing _Safe_sequence_base. If > > such an object completes construction before mutex_pool > > initialization, it will be registered for atexit destruction after the > > mutex_pool mutexes, so the _M_detach_all() call in the > > _Safe_sequence_base dtor will use already-destructed mutexes, and > > basic_string/requirements/citerators_cc fails calling terminate. > > Here's an alternative approach, with zero runtime overhead. Negative > overhead, if you count the time it would have taken to destruct the > mutex pool :-) But it fails to destruct them, which is presumably of no > consequence. > Agreed, I was going to suggest we immortalise them like this. > [libstdc++] do not destruct mutex_pool mutexes > > [Copy of the paragraph quoted above omitted here] > > This patch fixes this problem by ensuring the mutex pool mutexes are > constructed on demand, on a statically-allocated buffer, but never > destructed. > > Regstrapped on x86_64-linux-gnu. > Tested on arm-vxworks7 (gcc-12) and arm-eabi (trunk). Ok to install? > OK, thanks. > for libstdc++-v3/ChangeLog > > * src/c++11/shared_ptr.cc (__gnu_internal::get_mutex): > Avoid destruction of the mutex pool. > --- > libstdc++-v3/src/c++11/shared_ptr.cc | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/libstdc++-v3/src/c++11/shared_ptr.cc > b/libstdc++-v3/src/c++11/shared_ptr.cc > index bc70134359c87..74e879e582896 100644 > --- a/libstdc++-v3/src/c++11/shared_ptr.cc > +++ b/libstdc++-v3/src/c++11/shared_ptr.cc > @@ -36,7 +36,11 @@ namespace __gnu_internal _GLIBCXX_VISIBILITY(hidden) > { > // increase alignment to put each lock on a separate cache line > struct alignas(64) M : __gnu_cxx::__mutex { }; > - static M m[mask + 1]; > + // Use a static buffer, so that the mutexes are not destructed > + // before potential users (or at all) > + static __attribute__ ((aligned(__alignof__(M)))) > + char buffer[(sizeof (M)) * (mask + 1)]; > + static M *m = new (buffer) M[mask + 1]; > return m[i]; > } > } > > -- > Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ > Free Software Activist GNU Toolchain Engineer > Disinformation flourishes because many people care deeply about injustice > but very few check the facts. Ask me about > --000000000000f947d305f4e342cc--