3

I'm overriding C++ global new/delete operators on Linux project. It all works nicely in my own code, until I found out that the new/delete symbols in system libraries gets also replaced with my code! This is a very bad problem since it goes way beyond 'level of evil' I intended.

So question is how do I prevent the linker/compiler from replacing the new/delete syms from other (system) shared libraries? Or more precisely how do I control what shared libraries link syms from my library? I would want that the system libraries would still use their default new/delete implementation. Especially when the executable later loads other optional dynamic libraries with dlopen() that are not under my control.

The custom global new/delete operator implementation is build into a shared library.

I searched all over the Internet how to control the dynamic linking but didn't succeed. I first tries change the library link order on the test executable but that didn't change anything.

JATothrim
  • 842
  • 1
  • 8
  • 24
  • 2
    You're using the wrong customization point. Replacing the global operators is useful if you genuinely want to make this change everywhere. If you only want to customize allocation in a localized library, you should use some other mechanism (e.g. allocators) to provide a customization point. – Kerrek SB May 10 '16 at 17:45
  • 2
    Consider overloading the new and delete operators on your classes only. If you have a base class for most of your objects, do it there. This should cover a large portion of the memory you are using. You can then prob create custom STL allocators in the cases where you need to manage your objects inside of STL containers. – Arno Duvenhage May 10 '16 at 18:30
  • Overloading the new/delete only in common 'root' class would not help me in situations such as having plain function allocating raw memory. Refactoring a lot of code to use custom base new/delete would be tedious. I'm looking in possibility to LD_PRELOAD the allocator to test it on other C++ programs. – JATothrim May 10 '16 at 19:12

1 Answers1

2

I found out that the new/delete symbols in system libraries gets also replaced with my code!

You can read an explanation for why this happens here.

So question is how do I prevent the linker/compiler from replacing the new/delete syms from other (system) shared libraries?

You can make your ::operator new and ::operator delete private to your library by building with -fvisibility=hidden and explicitly marking the functions you do want to export with __attribute__((visibility("default"))). Alternatively, you could use linker version script to achieve the same result.

Community
  • 1
  • 1
Employed Russian
  • 199,314
  • 34
  • 295
  • 362
  • I knew linux .so libraries are very different from win .dlls. But I did not know dynamic syms resolved in executable would link like archive files requiring to have single definition across all linked code. So it seems to be impossible to do in *nix.. too bad. Thanks still! I'm already using the -fvisibility=hidden to compile the binaries and marking exported funcs in code. – JATothrim May 14 '16 at 19:34
  • 1
    Too bad it doesnt work in this supermarket operating system. I marked the project with -fvisibility=hidden, marked the operator new with __attribute__((visibility("hidden"))). Still my system library is overriden by my operator – Martin Kosicky May 03 '17 at 09:00