From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 3052A385842C; Mon, 8 Jan 2024 09:43:36 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3052A385842C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1704707016; bh=bdOypTSA5OSI4zRso8eeW7tnGziPww9IWdnlD8XAvu8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=SbwBK2vlnXB7oDNCFbabENgowroqJM5PCSNWCAwigIeDqMjcp2mxzZdzNwQVaw7gQ cVeyW6l1M0zFar2mqyy5TCnWFoPBbxZE3hvaXrERrGXz9JGURkFg9jMMRvnSIuSy4p u/HJJg8usCjw6ETG5FJKYHmYUMddhnJcie5JQpcs= From: "redi at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/113258] Pre-C++17 code that supplies operator new/delete crashes when mixed with post-C+17 code that uses the align_val_t variants of new/delete Date: Mon, 08 Jan 2024 09:43:31 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libstdc++ X-Bugzilla-Version: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: redi at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: INVALID X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D113258 --- Comment #17 from Jonathan Wakely --- (In reply to Nicholas Miell from comment #14) > Again, this version of tcmalloc predates aligned_alloc and the align_val_t > versions of operator new and delete. >=20 > Again, the C++ standard does not require the application to displace > aligned_malloc when it displaces operator new or delete. >=20 > Again, it is libstdc++ that is calling aligned_alloc, not the application. >=20 > Again, the application displaced all the versions of operator new and del= ete > that were present in the version of the C++ standard that it targeted, in > addition to all the C malloc functions in the C standard it targeted. Replacing malloc and free is not allowed by the standard at all, so this is already outside the standard. > Again, libstdc++ broke the ABI when it introduced the align_val_t versions > of operator new and delete because existing correctly functioning > applications stopped working in the presence of the new version of libstd= c++. >=20 > Again, libstdc++ has elected to provide only one version of the C++ runti= me > implementation that supports multiple versions of the C++ standard > simultaneously, instead of forking the library for every new revision of = the > language standard. >=20 > Again, you could probably fix this issue by implementing all of the newly > introduced versions of operator new and delete solely using the versions = of > operator new and delete that were present when libstdc++.so.6 was first > introduced. We could do that, or we could just implement the aligned new in terms of ma= lloc and over-allocate and manually align in the buffer (which is what we have t= o do for some targets without aligned_alloc or anything similar). But that sucks, and wastes memory and cycles. If aligned_alloc is supported, we use it. And that means we use free too. > Attempting to stick the blame on something other than libstdc++ doesn't e= ven > solve the problem of the application crashing at startup, ultimately it w= ill > have to be libstdc++ that works around this issue regardless. The > application certainly isn't getting updated, nor should it require updati= ng; > that's the whole point of having ABIs in the first place. >=20 > The C++23 standard says that whether the default versions of operator new > "involves a call to the C standard library functions malloc or aligned_al= loc > is unspecified." I assert that a C++ runtime that purports to simultaneou= sly > implement both C++14 and previous (which do not have aligned_alloc) and It's irrelevant whether C++14 has aligned_alloc, since libstdc++ doesn't provide that anyway. What matters is whether the underlying libc provides i= t. If it does, we call it. > C++17 and later (which do have aligned_alloc) must not call aligned_alloc= in > the default behavior of any version of operator new as a basic quality of > implementation detail, given that C++14 and previous applications (which = the > C++ runtime explicitly supports) are allowed to displace operator new and > delete without any knowledge of aligned_alloc. The problem has ABSOLUTELY NOTHING to do with replacing new/delete, it's ENTIRELY due to replacing malloc/free. You would get exactly the same problem in C code if your library using an o= ld tcmalloc was called by a new application that used aligned_alloc and then called free, resulting in a call to the old tcmalloc free. This is not a libstdc++ problem, nor a C++ problem. If you want to blame the ABI break on something, blame C11 for adding aligned_alloc and requiring that free can handle it. Libstdc++ has no way to know if the version of free present at runtime can handle aligned_alloc. Al= l we can tell is that aligned_alloc exists, we can't tell whether some library t= hat might be linked to later breaks the libc ABI by replacing free in a way that makes aligned_alloc unusable.=