Created attachment 101697 [details] C++ code used and valgrind -v output When using placement new in C++, as object is constructed in allocated storage, this should not leak. However, valgrind complains about memory leaks, and says there are 2 allocs and 1 free. Yet here is the output of `ltrace -e malloc+free` libstdc++.so.6->malloc(4) = 0x55bd51c93c20 libstdc++.so.6->free(0x55bd51c93c20) = <void> +++ exited (status 0) +++ You can find the code I used in attachment, compiled with g++ 6.2 with -std=c++14. Here is the output of `uname -a` : Linux Infinity 4.4.0-30-generic #49-Ubuntu SMP Thu Jun 30 20:51:32 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux The output of `valgrind -v` may also be found in attachment.
Not a bug. See https://bugs.kde.org/show_bug.cgi?id=345307 for an explanation.
Well it might be the same as that or it might not - it's hard to tell because the leak details have been suppressed from the log.
Also that code doesn't even compile: bericote [/tmp] % g++ -std=c++14 -o x x.cpp x.cpp: In function ‘int main()’: x.cpp:12:17: error: no matching function for call to ‘operator new(sizetype, A*&)’ new (obj) A(20); ^ <built-in>: note: candidate: void* operator new(long unsigned int) <built-in>: note: candidate expects 1 argument, 2 provided
I'm pretty sure it's not the same anyway as the other bug is about static objects, and there are none here. This is almost certainly something different - the fact that it is reporting two allocations suggests that it is trapping the placement new and treating it as a real allocation that is then never freed.
Sorry, I forgot to mention that you need to include <new> to make it compile.
So this is the leak it is reporting: ==24123== 72,704 bytes in 1 blocks are still reachable in loss record 1 of 1 ==24123== at 0x62228BAD: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==24123== by 0x624C0A5F: ??? (in /usr/lib64/libstdc++.so.6.0.22) ==24123== by 0x6160CD89: call_init.part.0 (in /usr/lib64/ld-2.23.so) ==24123== by 0x6160CE9A: _dl_init (in /usr/lib64/ld-2.23.so) ==24123== by 0x615FDCB9: ??? (in /usr/lib64/ld-2.23.so) So it's nothing to do with the placement new but rather is some initialisation inside the standard library. It's also still reachable when the program terminates, so not really a leak at all, which is why the details aren't shown by default. In the newly released 3.12.0 it goes away anyway because we now call the libstdc++ cleanup routine at exit by default.