CODEWITHSUNDEEP
c++memory-leaksc++11shared-ptrsmart-pointers
aiman09
aiman09

Reputation: 105

Global smart pointer is not cleaning up properly

I have a c++ interface, and the derived class of that interface in one DLL, I am using the class in another process by including the interface header file, and importing a factory function that returns an object of the derived class (COM style):

MyInterface
{
public:
 virtual ~MyInterface(){}
 virtual A() = 0;
}

MyDerivedClass : MyInterface
{
 public:
 virtual ~MyDerivedClass (){...};
 A(){...};
}

__declspec(dllexport) MyInterface* getObject()
{
 return (new MyDerivedClass());
}

When I test in my DLL (unit testing), I do like this:

std::tr1::shared_ptr<MyInterface> MyInterfaceObj; //global

func1() //initilize
{
 std::tr1::shared_ptr<MyInterface> temp(getObject());
 MyInterfaceObj.swap(temp);
}

func2()
{
 //use MyInterfaceObj;
}

everything is OK, I use visual leak detector, no complains, and I can see that MyDerivedClass destructor is called.

however, when I do exactly the same thing in my process (which loads the DLL), MyDerivedClass destructor is never called, and VLD complains about memory leaks.

BUT, if I declare everything inside func2() [in my process], everything works fine, no leaks and the destructor is called:

func2()
{
 std::tr1::shared_ptr<MyInterface> MyInterfaceObj; // not global anymore
 std::tr1::shared_ptr<MyInterface> temp(getObject());
 MyInterfaceObj.swap(temp); //I know this is useless here, just wanted to have the same steps as before
 //use MyInterfaceObj;
}

I need to have the first structure in my process (a global variable, initialized by one function, then used inside a heart beat function).

Any Idea why this happens ?!, I tried to make a function to release the memory (it has "delete this") and pass it to the smart pointer constructor, but it does not change anything.

(using visual c++ 2008 sp1)

Upvotes: 2

Views: 1944

Answers (1)

Mark Ransom
Mark Ransom

Reputation: 308206

The order of destruction of globals isn't guaranteed. In the case of your test code in the DLL it's obviously destroying the global before the leak detection occurs, but when you have it in the application it doesn't. It will still be destroyed before the application exits.

When you have the variable inside a function rather than global, it will only exist within the scope of the function. It will be destroyed at the end of the function.

Upvotes: 3

Related Questions