From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 110953 invoked by alias); 7 Feb 2018 23:59:40 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 110001 invoked by uid 89); 7 Feb 2018 23:59:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=H*f:sk:185562e, H*i:sk:185562e, cin, management X-HELO: mail-it0-f41.google.com Received: from mail-it0-f41.google.com (HELO mail-it0-f41.google.com) (209.85.214.41) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 07 Feb 2018 23:59:37 +0000 Received: by mail-it0-f41.google.com with SMTP id u12-v6so16980998ite.0 for ; Wed, 07 Feb 2018 15:59:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UzmS7bDOz2BXY7gFvujilycXBqF58kpAbgaUkthdzTE=; b=Q6L+hj8aVUyKWLl4akHq+rvf3rwKRVbuIro1tj05hHjnifnsQEX2tWhjkQmM5kWgLV AjAx+rmjBFahZTwjvFjg9zHRVR8P6QZV8maKVFoLQYEpqfeyiq8+mLTaGQQ2QJsLXS+P QMMfpchvlsEyOFSJT8S9KReYMvhQR0TiL2bcTlx9K3S53wwLaC/A8HV0jAFo2sknZ24/ IB5mnC4UdjTbVxfAiyWUP5AujnOewLhwD2TWH8qPBYD9iDtoUkQ5ek0XN35er5Grj/am WTUiXauMdy6bPSe9/sgS1bn5OJ7oFpVuGzIt8UW+ArGGRvRvwB0J5/li7UIijmED4s0K 7yyg== X-Gm-Message-State: APf1xPCNSqq3CL+E4VEZZWy3eXYGuHkP39MGQG8woVzvnQxT9HQLbocl EFGzmKhuQgZC1vGoA7fBx2EIexhSxR5Q6JuJvPw= X-Google-Smtp-Source: AH8x227TiwuSu3+C5g0s0rt81pVnfxB2Y8oLMdzdPgUv30DH7mIbIBRGHZ4nLkNNjTCAPntRpznXLSh6SvXDh2fAd0M= X-Received: by 10.36.253.6 with SMTP id m6mr10570139ith.132.1518047976157; Wed, 07 Feb 2018 15:59:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.50.198 with HTTP; Wed, 7 Feb 2018 15:59:35 -0800 (PST) In-Reply-To: <185562e1-26a6-6c7f-a5c1-c4272ceb3bfc@gmail.com> References: <1517957793.10111.138.camel@mad-scientist.net> <185562e1-26a6-6c7f-a5c1-c4272ceb3bfc@gmail.com> From: Jonathan Wakely Date: Wed, 07 Feb 2018 23:59:00 -0000 Message-ID: Subject: Re: gcc 7.3: Replacing global operator new/delete in shared libraries To: Paul Smith Cc: "gcc@gcc.gnu.org" , Martin Sebor Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-02/txt/msg00090.txt.bz2 On 7 February 2018 at 23:38, Martin Sebor wrote: > On 02/06/2018 03:56 PM, Paul Smith wrote: >> >> Hi all. >> >> Hopefully this isn't too annoying a question :). >> >> My environment has been using GCC 6.2 (locally compiled) on GNU/Linux >> systems. We use a separate heap management library (jemalloc) rather >> than the libc allocator. The way we did this in the past was to >> declare operator new/delete (all forms) as inline functions in a header >> and ensure that this header was always the very first thing in every >> source file, before even any standard header files. I know that inline >> operator new/delete isn't OK in the C++ standard, but in fact it has >> worked for us on the systems we care about. > > > I don't know if something has changed that would expose this > problem but... > > I'm not sure I see how defining operator new inline can work > unless you recompile the world (i.e., all the DSOs used by > the program, including libstdc++). As Marc already hinted, > if libstdc++ dynamically allocates an object using the default > operator new and returns that object to the program to destroy, > it will end up causing a mismatch. And without actually checking the code, I'm pretty sure that's what happens in this case: #include int main() { std::string s; std::cin >> s; } The code to read a string from an istream is instantiated in the library, so the string gets resized (allocating using malloc) by code inside libstdc++.so.6 and then the destructor is run (deallocating using your inline operator delete) in main. That would be my first guess at explaining the stack trace you showed.