Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Memory leak check for MSVC #439

Closed
prapin opened this issue Jun 18, 2015 · 4 comments
Closed

Memory leak check for MSVC #439

prapin opened this issue Jun 18, 2015 · 4 comments

Comments

@prapin
Copy link

prapin commented Jun 18, 2015

Visual Studio C runtime has a debugging mechanism to spot memory leaks.
In the main function, _CrtSetDbgFlag can be used to enable that mechanism.
When CATCH returns after having executed all tests, MSVC displays the list of memory blocks that have not be freed.
By setting _crtBreakAlloc and rerun the test, CATCH will stop at the allocation of the leaked block
(provided the allocation sequence is exactly the same).

See my commit for reference:
prapin@a4695cc

@prapin
Copy link
Author

prapin commented Jul 7, 2015

The _CRTDBG_DELAY_FREE_MEM_DF flag in my reference commit should in fact be avoided, as it will prevent memory from being physically released.
We only need _CrtSetDbgFlag(_CRTDBG_LEAK_CHECK_DF | _CRTDBG_ALLOC_MEM_DF);

@horenmar
Copy link
Member

If I understand this correctly, its a recommendation/request to hook up with MSVC CRT leak checker into Catch's main, so that memory leaks in tested code can be found?

That is potentially very interesting addition but it might be a while before I can get around to it (but seeing how the issue is from 2015, its been a while anyway).

@alkhimey
Copy link

It appears in the release notes of https://github.com/philsquared/Catch/releases/tag/v1.8.0. Is this the same feature as described in this issue?

@horenmar
Copy link
Member

@alkhimey yes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants