views:

60

answers:

3

Hi,

I have a test app that is linked with some DLLs (or .so's). In my main app I defined a global new/delete like this:

void* operator new(size_t n)
{
    ....
}

void operator delete(void* p)
{
    ...
}

But I noticed the operators are only called for things I allocate in my main app, but not if one of the DLLs does.

How do I make allocations in the DLLs go through my operator new/delete? (This should also include memory allocated by STL, so if one of the DLLs has an std::string, I'd like my operator new to be called when STL allocates its std::string internal buffer).

I'm more interested in a Windows solution, but a Linux one would also be appreciated.

edit: perhaps I wasn't clear originally, this test app I was doing was meant to track memory usage for a few auto-generated classes defined in a DLL. Creating my own allocator and using that in the generated code STL structures isn't an option, more so there are other non-STL allocations. But seeing the answers, I think the best option is either to use a profiler or simply monitor the memory usage using perfmon.

+2  A: 

I'd like my operator new to be called when STL allocates its std::string internal buffer

typedef std::basic_string<char, std::char_traits<char>, ALLOCATOR> mystring;

The code in the DLLs already uses its own new implementation, and there's no good reason why defining your own implementation should magically change the implementation that the DLLs use (what if they use their own custom implementation?).

So if you want the strings to use your allocator, you need to explicitly create them as such.

taspeotis
@taspeotis: can we track STL allocations in the way you mentioned ? how to use mystring ? Its not calling my own new :(
bjskishore123
@bjskishore123 - use you can track STL allocations like that. You use `mystring` like `std::string`, except replace `ALLOCATOR` with your own implementation of the allocator.
taspeotis
although your answer is technically correct, it doesn't really help me. more so, the DLLs are mine - they don't have their own `new` implementation and I can recompile them to use the one in the test app - if I knew how.
Zack
+1  A: 

Anything that is intended to use your global definitions must be compiled with those definitions available. The technique you use will not override anything already compiled in DLLs or even other source files that don't include these definitions. In many cases the allocators and standard functions will also not use these functions even when visible.

If you really need to do this you'll have to intercept calls to malloc (and other allocation routine). This isn't easy. You can't simply do it from the code. You'll have to tell the linker how to do this. On Linux I think this is LD_PRELOAD, though I can't remember, and on Windows I'm not sure at all.

If you can indicate why you'd like to do this perhaps I can offer an alternate solution.

edA-qa mort-ora-y
thanks, see my edit for more info
Zack
Yes, a profiler will be your best bet. Look at valgrind on Linux.
edA-qa mort-ora-y
+1  A: 

There is no way to completely do what you want to do. There are too many corner cases where memory is leaked.

The closest I think you can get is by doing the following: Each class in your dll/.so will have to have a static factory/destroy method. Pass a pointer to an allocation function to the factory and the deallocation function to the destroy method in each class in each dll/.so.

For an example of how to get close, google for the HORDE memory allocation library, which does get close.

Another thing to look at is the various C++ class plugin libraries that allow you to load any dll/.so as a plugin. Last time I checked there were at least 10 such libraries with source in the googlesphere. :)

JimR