Memory leak in main

[HollingsworthDan]

This memory leak keeps tripping my leak detection can we get this fixed?

	// Connect and start the event loop
	connectionManager->Run();

	return 0;
}

should look more like :

	// Connect and start the event loop
	connectionManager->Run();

	delete connectionManager;

	return 0;
}

Cheers

[Timac]

Thanks for reporting this problem. You are right that the connectionManager is not deleted. If you make a PR, we can merge it.

Since this delete is missing just before the plugin is quit, this really isn't a memory leak. I would however be interested to know which tool you are using for the leak detection. I don't see such a warning with the Clang Static Analyzer.

[HollingsworthDan]

Hi Alexandre,

I have my own proprietary tools.

But if you are interested. Windows have a ton of heap debugging tools. Every allocation and free that goes to the OS will get a callstack pulled.

The information is not very digestible at first. But when you parse it and throw it into a DataSet form, and sort the callstacks by the number of remaining allocations you get a list of leaks at the top of the form.

It's not real time, you have to poll for the state of the heap. And then delta with the previous state to get changes. But the state is the current state at the time of the call. And thats all you need for leak checks.

If you are interested in Deploying a similar solution within your own studio I could Provide you those tools, for a nominal fee.

And you are correct, once the process handle is signaled, all memory pools dedicated to the process will be reclaimed.

Cheers,

Dan -

On Fri, May 29, 2020 at 9:32 AM Alexandre Colucci [email protected] wrote:

Thanks for reporting this problem. You are right that the connectionManager is not deleted. If you make a PR, we can merge it.

Since this delete is missing just before the plugin is quit, this really isn't a memory leak. I would however be interested to know which tool you are using for the leak detection. I don't see such a warning with the Clang Static Analyzer.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/elgatosf/streamdeck-cpu/issues/9#issuecomment-636037905, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADS63JLEB2AKVLUIYFSK6YLRT7IQ7ANCNFSM4NIE22AQ .

[Timac]

Hey Dan,

Thanks a lot for the info. We are using several of these tools ourselves but none of them reported this potential leak. That's why I was curious about it. For example we use the Clang Static Analyzer for detecting problems at compile time. We are also using Instruments on macOS to detect leaks at runtime. I assume that your solution would be fairly similar to Instruments.

[HollingsworthDan]

It runs incredibly sloooooow.. If that's what instruments does. It uses the debug version of the kernel32.DLL's and pulls a callstack info.

This was part of the performance tools for windows back in Win 7 & 8. Looks like they have integrated those features with Visual Studio in Windows 10. (which is probably much safer than my tools on Win 10.)

Cheers,

Dan "The Bug King" Hollingsworth

On Fri, May 29, 2020 at 11:07 AM Alexandre Colucci [email protected] wrote:

Hey Dan,

Thanks a lot for the info. We are using several of these tools ourselves but none of them reported this potential leak. That's why I was curious about it. For example we use the Clang Static Analyzer for detecting problems at compile time. We are also using Instruments on macOS to detect leaks at runtime. I assume that your solution would be fairly similar to Instruments.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/elgatosf/streamdeck-cpu/issues/9#issuecomment-636083247, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADS63JOQDROGYQBBUDWYWDLRT7TWBANCNFSM4NIE22AQ .