Memory Leak detected for tf::Taskflow v3.3.0 onwards (False Positive) #1701
Comments
coder137
changed the title
|
Most likely this involves a static variable somewhere that is allocated during the test and not freed at the end. If you want to figure out what it is, I recommend calling crash_on_allocation_number(7) in your test. This will crash CppUTest on the 7th allocation (which according to the error message was the leak). You can then run it in a debugger and check the stack trace, which will point you to the place where the memory is allocated (and probably to the static). Good luck! |
|
Thanks for the answer, I was able to find the global/static variable that was causing the problem. Will update my analysis here for those that have a similar problem with CppUTest and Taskflow File: template <typename T, size_t S>
template <typename... ArgsT>
T* ObjectPool<T, S>::animate(ArgsT&&... args) {When creating a new block // create a new block
else {
//printf("create a new superblock\n");
_gheap.mutex.unlock();
f = 0;
//s = static_cast<Block*>(std::malloc(sizeof(Block)));
s = new Block(); // This is flagged as a leakThe earlier implementation (before v3.3.0), used malloc instead of new which is why the CppUTest memory leak detector did not flag this as a leak. The ObjectPool is instantiated globally in the header file like this inline ObjectPool<Node> node_pool; |
|
@basvodde Since this global variable is causing a problem are there workarounds to this? I do not want to completely turn off the Memory Leak detector plugin in CppUTest and my project has a hard dependency on Taskflow. Any help would be appreciated. |
|
Yes, there is a standard workaround for this, actually two. If it is possible, then you can release the static within the test. So... in your case... is there a way to release that Block via some function call such as "clearAllCachedBlocks". When you test-drive with CppUTest then typically you always create such a function to make sure that the tests also releases global/static data. If that is not possible (and I suspect that this is the case) then the common workaround is to try to allocate that static in the main. The memory leak detector works per test, so when the static is allocated before the test starts then it will not flag it as a leak. So, it is not uncommon to have a main that creates a bunch of objects to get all the uncontrollable statics/globals initialized and then it starts the tests. If you can, option 1 is best. If you must, option 2 is almost always possible. |
|
@tsung-wei-huang Sure. By default, in CppuTest, the operator new is overloaded to keep track of memory allocated so that it can discover memory leaks. The malloc is not overloaded by default as there is no C language support for overloading that. It is still possible through a #define which replaces malloc with cpputest_malloc... but then that only works when you compile all of your code with that #define enabled. (this is possible by adding --include MemoryLeakDetectorMalloc.h to the compiler options of your product). Thus by switching from malloc to switch, it enabled CppUTest to discover the memory allocation, keep track of it, and it discovered it was not released within the test where it was allocated (because of the static). |
Cross-posting from here: taskflow/taskflow#450
Test setup being used
Error Output
Memory leak is detected
Other information
According to the thread there was a race condition that was eliminated as well as other thread_local static variables removed
The text was updated successfully, but these errors were encountered: