c958e26fd0
Add a new RAII MemoryIsNotDeallocated class that excludes memory allocations from Microsoft’s debug CRT leak detection report.
We use this RAII class to silence 2 false positive leaks that are caused by memory allocations that are intentionally never deallocated.
*Background*
The MS debug CRT has a lightweight memory leak detection mechanism that can only detect if a memory allocation is missing a matching deallocation.
Consequently, it will report a false positive leak for memory that’s intentionally never deallocated. For example, memory that’s reachable for the entire lifetime of a app.
Note the MS debug CRT is always tracking memory allocations but the final memory leak report is disabled by default. As you can’t avoid paying for its cost, you may as well use it.
The memory leak report can be enabled by calling the following function
#ifdef _MSC_VER
_CrtSetDbgFlag(_CrtSetDbgFlag(_CRTDBG_REPORT_FLAG) | _CRTDBG_LEAK_CHECK_DF);
#endif // _MSC_VER
anywhere before exiting main.
For example, the following are the false positive leaks reported before this change;
Detected memory leaks!
Dumping objects ->
{750} normal block at 0x015DF938, 8 bytes long.
Data: < ] > 00 F9 5D 01 00 00 00 00
{749} normal block at 0x015DEE60, 32 bytes long.
Data: <` ] ` ] ` ] > 60 EE 5D 01 60 EE 5D 01 60 EE 5D 01 01 01 CD CD
{748} normal block at 0x015DF900, 12 bytes long.
Data: <8 ] ` ] > 38 F9 5D 01 60 EE 5D 01 00 00 00 00
{747} normal block at 0x015DA0F8, 24 bytes long.
Data: < > FF FF FF FF FF FF FF FF 00 00 00 00 00 00 00 00
Object dump complete.
As you can see from above it’s not easy to identify the above are false positives. Consequently, if false positive leaks are not fixed or silenced, then it becomes impractical to identify real memory leaks.
|
||
|---|---|---|
| googlemock | ||
| googletest | ||
| .gitignore | ||
| .travis.yml | ||
| appveyor.yml | ||
| CMakeLists.txt | ||
| README.md | ||
| travis.sh | ||
Google Test
Welcome to Google Test, Google's C++ test framework!
This repository is a merger of the formerly separate GoogleTest and GoogleMock projects. These were so closely related that it makes sense to maintain and release them together.
Please see the project page above for more information as well as the mailing list for questions, discussions, and development. There is also an IRC channel on OFTC (irc.oftc.net) #gtest available. Please join us!
Getting started information for Google Test is available in the Google Test Primer documentation.
Google Mock is an extension to Google Test for writing and using C++ mock classes. See the separate Google Mock documentation.
More detailed documentation for googletest (including build instructions) are in its interior googletest/README.md file.
Features
- An XUnit test framework.
- Test discovery.
- A rich set of assertions.
- User-defined assertions.
- Death tests.
- Fatal and non-fatal failures.
- Value-parameterized tests.
- Type-parameterized tests.
- Various options for running the tests.
- XML test report generation.
Platforms
Google test has been used on a variety of platforms:
- Linux
- Mac OS X
- Windows
- Cygwin
- MinGW
- Windows Mobile
- Symbian
Who Is Using Google Test?
In addition to many internal projects at Google, Google Test is also used by the following notable projects:
- The Chromium projects (behind the Chrome browser and Chrome OS).
- The LLVM compiler.
- Protocol Buffers, Google's data interchange format.
- The OpenCV computer vision library.
Related Open Source Projects
Google Test UI is test runner that runs your test binary, allows you to track its progress via a progress bar, and displays a list of test failures. Clicking on one shows failure text. Google Test UI is written in C#.
GTest TAP Listener is an event listener for Google Test that implements the TAP protocol for test result output. If your test runner understands TAP, you may find it useful.
Requirements
Google Test is designed to have fairly minimal requirements to build and use with your projects, but there are some. Currently, we support Linux, Windows, Mac OS X, and Cygwin. We will also make our best effort to support other platforms (e.g. Solaris, AIX, and z/OS). However, since core members of the Google Test project have no access to these platforms, Google Test may have outstanding issues there. If you notice any problems on your platform, please notify googletestframework@googlegroups.com. Patches for fixing them are even more welcome!
Linux Requirements
These are the base requirements to build and use Google Test from a source package (as described below):
- GNU-compatible Make or gmake
- POSIX-standard shell
- POSIX(-2) Regular Expressions (regex.h)
- A C++98-standard-compliant compiler
Windows Requirements
- Microsoft Visual C++ v7.1 or newer
Cygwin Requirements
- Cygwin v1.5.25-14 or newer
Mac OS X Requirements
- Mac OS X v10.4 Tiger or newer
- Xcode Developer Tools
Requirements for Contributors
We welcome patches. If you plan to contribute a patch, you need to build Google Test and its own tests from a git checkout (described below), which has further requirements:
- Python v2.3 or newer (for running some of the tests and re-generating certain source files from templates)
- CMake v2.6.4 or newer
Regenerating Source Files
Some of Google Test's source files are generated from templates (not in the C++ sense) using a script. For example, the file include/gtest/internal/gtest-type-util.h.pump is used to generate gtest-type-util.h in the same directory.
You don't need to worry about regenerating the source files
unless you need to modify them. You would then modify the
corresponding .pump files and run the 'pump.py'
generator script. See the Pump Manual.
Contributing Code
We welcome patches. Please read the Developer's Guide for how you can contribute. In particular, make sure you have signed the Contributor License Agreement, or we won't be able to accept the patch.
Happy testing!