2

I've been having memory leak issues with my application, and as it's in the physics module (which almost everything uses) it's causing a lot of slow down in the application. By using Visual Leak Detector i identified that the majority of the leaks were occurring due to the constructor, and the ApplyGravity function.

ParticleModel::ParticleModel(Transform* transform)
{
 _transform = transform;
 Acceleration = XMFLOAT3(0.0f, 0.0f, -0.1f);
 mass = 10.0f;
 force = XMFLOAT3(0.0f, 0.0f, 0.0f);
 velocity = XMFLOAT3(0.0f, 0.0f, 0.0f);
 netForce = XMFLOAT3(0.0f, 0.0f, 0.0f);
 forceMag = 0.0f;
 sForce = XMFLOAT3(0.0f, 0.0f, 0.0f);
 dragFactor = 1.0f;
 gravity = -9.81f;

 _usingGravity = false;
 _useConstAcc = true;
 laminar = true;

 radius = 0.5f;

 CollisionCheck = false;

 boolsForce = true;

 move.x = 0.0f;
 move.y = 0.0f;
 move.z = 0.0f;
 moveBy = 0.0f;
}

I commented out all of the variables aside from _transform = transform; and the memory leak from the constructor still occurred, also i side note is that i am freeing the memory of the pointer in the destructor of the class, although i'm not sure if this is the best place to be doing it.

ParticleModel::~ParticleModel()
{
    delete _transform;
}

The second memory leak in ApplyGravity:

void ParticleModel::ApplyGravity()
{
  _temp = XMFLOAT3(0.0f, gravity, 0.0f);
  _forces.push_back(_temp); //_forces is a vector of XMFLOAT3s 
}

I've played with Clearing the vector, but to no avail as the leak still occurs.

Output:

Leak Hash: 0x5522F309, Count: 1, Total 12 bytes
  Call Stack (TID 1556):
   MSVCR120D.dll!operator new()
c:\program files (x86)\microsoft visual studio 12.0\vc\include\xmemory0 (848): DX11 Framework.exe!std::_Wrap_alloc<std::allocator<DirectX::XMFLOAT3> >::allocate()
c:\program files (x86)\microsoft visual studio 12.0\vc\include\vector (1588): DX11 Framework.exe!std::vector<DirectX::XMFLOAT3,std::allocator<DirectX::XMFLOAT3> >::_Reallocate() + 0x17 bytes
c:\program files (x86)\microsoft visual studio 12.0\vc\include\vector (1619): DX11 Framework.exe!std::vector<DirectX::XMFLOAT3,std::allocator<DirectX::XMFLOAT3> >::_Reserve()
c:\program files (x86)\microsoft visual studio 12.0\vc\include\vector (1258): DX11 Framework.exe!std::vector<DirectX::XMFLOAT3,std::allocator<DirectX::XMFLOAT3> >::push_back()
 particlemodel.cpp (58): DX11 Framework.exe!ParticleModel::ApplyGravity()
particlemodel.cpp (290): DX11 Framework.exe!ParticleModel::Update()
gameobject.cpp (27): DX11 Framework.exe!GameObject::Update() + 0x1F bytes
 bbparticle.cpp (193): DX11 Framework.exe!BBParticle::Update()
smokeemitter.cpp (54): DX11 Framework.exe!SmokeEmitter::Update()
 application.cpp (1254): DX11 Framework.exe!Application::Update() + 0x30 bytes
main.cpp (67): DX11 Framework.exe!wWinMain()
 f:\dd\vctools\crt\crtw32\dllstuff\crtexe.c (466): DX11   Framework.exe!wWinMainCRTStartup()
 KERNEL32.DLL!BaseThreadInitThunk() + 0x24 bytes
 ntdll.dll!RtlUnicodeStringToInteger() + 0x253 bytes
 ntdll.dll!RtlUnicodeStringToInteger() + 0x21E bytes
    Data:
     00 00 00 00    C3 F5 1C 41    00 00 00 00                    .......A ........

All the other leaks that are occurring i assume are due to ParticleModel being called in all the locations listed in the output. For instance ParticleModel::Update() calls ApplyGravity, and what not.

MrPurple
  • 105
  • 1
  • 1
  • 7

2 Answers2

3

You say you delete the pointer in the destructor:

ParticleModel::~ParticleModel()
{
    delete _transform;
}

However, the constructor is not where this object gets allocated. It gets passed into the constructor, and set to the class member. One possible cause of the memory leak is that there are code paths where a new instance of this object gets allocated, but does not get stored anywhere, or passed to a new instance of ParticleModel, and, as such, never gets destroyed.

This violates the RAII model.

Additionally, this class probably violates the Rule Of Three, which could be another source of memory leaks. Even if this dynamically scoped object always gets passed to a constructor, without properly following the Rule Of Three a memory leak could still occur; paired together with likely memory corruption, as an extra bonus.

There's nothing else in the constructor that appears to allocate any memory, and could possibly leak anything. Tools that attempt to locate the sources of memory leaks are not always reliable, and their output is sometimes hard to understand.

It is always better to follow well-established design principles, and design your classes correctly, instead of forging full speed ahead wherever the wind blows, and rely on debugging tools to find and fix any problems that result.

In order to be able to verify that there could not possibly be any memory leaks, the RAII principle states that dynamically-scoped objects, or any resources of any kind, must be allocated in the constructor, and destroyed in the destructor (with the assignment operator correctly handling that process, in order to comply with the Rule Of Three). If you cannot track down the actual source of your memory leak, by redesigning your classes properly you're likely to end up fixing the underlying bug.

Community
  • 1
  • 1
Sam Varshavchik
  • 114,536
  • 5
  • 94
  • 148
0

You would have to explicitly delete in case of vector of pointers. Check this post, it might help you.. Does vector::erase() on a vector of object pointers destroy the object itself?

Also in ParticleModel, you commented out the constructor and you try deleting _transform ... err would that serve the purpose? :) .. I guess the issue is at the constructor invocation, please post detailed code..

Community
  • 1
  • 1
NirmalGeo
  • 773
  • 4
  • 12