summaryrefslogtreecommitdiffstats
path: root/googletest/samples/sample2.h
diff options
context:
space:
mode:
authorScott Slack-Smith <deenderah@gmail.com>2017-06-30 16:12:56 (GMT)
committerScott Slack-Smith <deenderah@gmail.com>2017-06-30 16:12:56 (GMT)
commitc958e26fd02d43a916ff297c89eee22166fe7be7 (patch)
tree005e48b6d74dd6a629fe826acc43db499e780ca3 /googletest/samples/sample2.h
parent4bab34d2084259cba67f3bfb51217c10d606e175 (diff)
downloadgoogletest-c958e26fd02d43a916ff297c89eee22166fe7be7.zip
googletest-c958e26fd02d43a916ff297c89eee22166fe7be7.tar.gz
googletest-c958e26fd02d43a916ff297c89eee22166fe7be7.tar.bz2
*Silence false positive memory leaks reported by Microsoft's debug CRT*
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.
Diffstat (limited to 'googletest/samples/sample2.h')
0 files changed, 0 insertions, 0 deletions