Didn't any body notice that there are a lot of memory leaks?

Create a lua project, open the solution with Visual Studio 2013, include <vld.h> in the main.cpp, compile, run and exit…

Visual Leak Detector detected 473 memory leaks (229769 bytes).
Largest number used: 464677 bytes.
Total allocations: 773777 bytes.
Visual Leak Detector is now exiting.
The program '[3332] YZBSG.exe' has exited with code 12869752 (0xc46078).

I’m using cocos2d-x 3.6, 3.7 also has same problem.

Just a heads up, at least for 2.2.6, VLD has a number of issues tracking scripted and GC’d script objects.

When I’m debugging or searching for memory leaks in complex C++ software, I rarely depend on VLD alone for the test.

Valgrind (Linux) and XCode’s excellent profiler (iOS and Mac) both give awesome additional information, and can help determine if VLD is lying or not.

@corytrese, thank you! I’ll try XCode’s later.

More information about my test:

  1. I use the latest VLD version: 2.4RC;
  2. Some (if not most) of the leaks are caused by the ‘simulator’ module and the cpp project has no leaks which don’t use the simulator.

A suspect memory leak source: SpriteFrameCacheHelper::addSpriteFrameFromFile() in .\frameworks\cocos2d-x\cocos\editor-support\cocostudio\CCSpriteFrameCacheHelper.cpp

Each time add a CocoStudio(1.x version) exported ‘.ExportJson’ file to ArmatureDataManager, the SpriteFrame objects created from that file will be retained for an extra time by calling SpriteFrameCacheHelper::retainSpriteFrames() from within SpriteFrameCacheHelper::addSpriteFrameFromFile().This extra reference would be released only if SpriteFrameCacheHelper::releaseSpriteFrames() are called manually with the same .plist file name as the argument. It won’t be released even with ccs.ArmatureDataManager:destroyInstance(), because the destructor of SpriteFrameCacheHelper do nothing with its private member: _usingSpriteFrames. And there is no guarantee that SpriteFrameCacheHelper::addSpriteFrameFromFile() and SpriteFrameCacheHelper::releaseSpriteFrames() be called in pairs.

My fix:

SpriteFrameCacheHelper::~SpriteFrameCacheHelper()
{
	for (auto iter = _usingSpriteFrames.begin(); iter != _usingSpriteFrames.end(); ++iter)
	{
		auto& vec = iter->second;
		auto itFrame = vec.begin();
		while (itFrame != vec.end())
		{
			CC_SAFE_RELEASE(*itFrame);
			++itFrame;
		}
		vec.clear();
	}
 	_usingSpriteFrames.clear();
}