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.