From: Jonathan Wakely <jwakely.gcc@gmail.com>
To: Paul Smith <paul@mad-scientist.net>
Cc: "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>, Martin Sebor <msebor@gmail.com>
Subject: Re: gcc 7.3: Replacing global operator new/delete in shared libraries
Date: Wed, 07 Feb 2018 23:59:00 -0000 [thread overview]
Message-ID: <CAH6eHdQjiL2tc0CDoD0waZ-Hb3TEwmRdnf3G32BzW0dUkaVAHQ@mail.gmail.com> (raw)
In-Reply-To: <185562e1-26a6-6c7f-a5c1-c4272ceb3bfc@gmail.com>
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 <iostream>
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.
next prev parent reply other threads:[~2018-02-07 23:59 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-06 22:57 Paul Smith
2018-02-07 10:32 ` Marc Glisse
2018-02-07 14:48 ` Paul Smith
2018-02-08 0:17 ` Marc Glisse
2018-02-08 0:42 ` Paul Smith
2018-02-07 23:38 ` Martin Sebor
2018-02-07 23:59 ` Jonathan Wakely [this message]
2018-02-08 0:26 ` Paul Smith
2018-02-09 4:47 ` Paul Smith
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAH6eHdQjiL2tc0CDoD0waZ-Hb3TEwmRdnf3G32BzW0dUkaVAHQ@mail.gmail.com \
--to=jwakely.gcc@gmail.com \
--cc=gcc@gcc.gnu.org \
--cc=msebor@gmail.com \
--cc=paul@mad-scientist.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).