- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
An MFC application is reporting many memory leaks at exit using MFC's internal mem leak checker.
Running Inspector didn't reveal those leaks.
I've read that MFC can falsly report leaks because linked DLLs allocate memory before MFC's memory tracker becomes active.
I tried linking to MFC's DLLs first via linker options (confirmed by viewing the linker output in VERBOSE mode). MFC links first but the leaks are still showing.
The application is linked with several boost DLLs as well as 2-3 user DLLs which are not MFC DLLs.
Happens also when boost is linked statically.
Just opening and closing the application dumps many (tens) small leaked objects in the output window by MFC's memory leak tracker.
All the reported leaks are simple pointers (not MFC objects) and no reference to the originating source code.
I have a few questions:
1) Does MFC use a custom allocator (e.g. not malloc) and thus fools Inspector XE?
2) Can I somehow disable MFC's special memory allocator in debug builds?
3) Are the leaks reported falsely by MFC if Inspector XE says nothing's wrong?
Setup:
* Window 7 64 bit sp1
* VS2012 and VS2010
* Building 64 bit MFC application
* Boost 1.52 either dynamically or statically linked.
* Intel Parallel Studio XE 2013 update 1
If anyone has a suggestion, please share :)
- Tags:
- CC++
- Debugging
- Development Tools
- Fortran
- Intel® Inspector
- Optimization
- Parallel Computing
- Vectorization
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
For years I didn't have any issues with MFC's memory leaks detector, it was very useful, only lately I came across this issue in a mature application.
I can't build the app in 32 bit or without boost.
I'll try to introduce various memory leaks within different modules of the application and see if they are caught by wither MFC or Inspector.
But before doing reverse engineering, maybe someone has some insight on the matter and maybe a workaround.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Inspector XE Update 4 contains some fixes for handling MFC's debug 'new'. The problem shows up as false reports of mismatched allocation/deallocation - IXE would miss the debug 'new', but catch the underlying malloc. It would subsequently see the 'delete', and report a problem.
Unfortunately, I don't think this fix will address the issue you're seeing, but it still may be worth trying the latest IXE update.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>> More technical details? A piece of code?
The code is an internal tool and I can't publically send pieces of it. When there were leaks in the executable (vs the DLLs) MFC reported them - it included a source name+line number in the report.
>> No and It doesn't "fool" Inspector XE.
It's possible to "fool" memory checkers by replacing malloc/new/new[] with different functions. When I used TBB malloc (highly recommended!) in Linux, various tools stopped reporting leaks. The replacement malloc or memory manager can call VirtualAlloc for large blocks and free everything at exit so no leaks will be detected. This behavior is normal for memory managers.
>> As soon as CRTDBG_MAP_ALLOC is defined then malloc is mapped to malloc_dbg. Take into account that there is a set of CRT-functions for allocation / deallocation of alligned memory ( it is documented in MSDN ).
If I remember correctly, malloc_dbg is identified by Inspector, so that would not help. I would cause problems (crash) when memory is freed across DLL borders.
>> I'd like to make a special post regarding a term False Memory Leaks widelly used by some software engineers:
If MFC memory leaks detection API ( based on _Crt<...> functions ) Reports a memory leaks it is Not a False one, and it is a Real one.
I've read reports that if globals are instantiated (and malloc) before MFC is loaded that can happen. I tried linking to MFC first so I believe the leaks are real.
As for the source of the leak, it indeed could be anywhere. Boost is my usual suspect. I'll post a dump from VS when I get back to work. Basically simple blocks ranging from 8-100 bytes. About 50 of them. Their contents look like pointers (4 non zero bytes followed by 4 zero bytes) - this is 64 bit builds.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Here's a sample of the dump, it's quite long but the rest don't reveal any more information:
Detected memory leaks!
Dumping objects ->
{7662} normal block at 0x0000000002760B80, 64 bytes long.
Data: <`qt rt > 60 71 74 02 00 00 00 00 00 72 74 02 00 00 00 00
{7371} normal block at 0x0000000002752BB0, 8 bytes long.
Data: <@ v > 40 AA 76 02 00 00 00 00
{7259} normal block at 0x0000000002766CB0, 24 bytes long.
Data: <P. > 50 2E F0 F2 FE 07 00 00 01 00 00 00 01 00 00 00
{7257} normal block at 0x0000000002766900, 16 bytes long.
Data: <8 & > 38 D1 26 00 00 00 00 00 00 00 00 00 00 00 00 00
{7256} normal block at 0x0000000002766850, 64 bytes long.
Data: <Phv Phv > 50 68 76 02 00 00 00 00 50 68 76 02 00 00 00 00
{7255} normal block at 0x000000000274AC20, 16 bytes long.
Data: < & > 08 D1 26 00 00 00 00 00 00 00 00 00 00 00 00 00
{7254} normal block at 0x000000000274ABB0, 8 bytes long.
Data: < & > E0 D0 26 00 00 00 00 00
{7253} normal block at 0x000000000274AB30, 24 bytes long.
Data: < % > A8 25 F0 F2 FE 07 00 00 02 00 00 00 02 00 00 00
{7252} normal block at 0x000000000274AA90, 48 bytes long.
Data: < t 0 t > 90 AA 74 02 00 00 00 00 30 AB 74 02 00 00 00 00
{7251} normal block at 0x000000000274AA10, 24 bytes long.
Data: <P. > 50 2E F0 F2 FE 07 00 00 01 00 00 00 01 00 00 00
This scenraio is just opening and closing the app.
MFC DLL (mfc100d.dll) is loaded around the middle of load list.
A few links for false MFC leaks:
http://stackoverflow.com/questions/628021/false-memory-leaks-in-a-mfc-project
Sergey, you're right that I'm speculating. At this stage I'm asking questions :)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sergey, I followed your comments as well as looked at the (few) resource and memory leaks leask reported by Inspector and found that the main problm was with boost::threadpool. The application seems to create and destroy the threadpool multiple times during the life cycle of the application. When turning the threadpool to a global, the memory leaks are greatly reduced.
Thanks a lot for your time and effort!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Well, I wasn't asking anyone to help me het rid of the leaks, just wanted to know how things work with MFC + Inspector.
I want to thank Sergey for his effort and time. I got my all my answers.
Also, thanks Mark for pointing me to the new version.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
May it's not relevant here, but I don't know where to post an IntelQuickSyncDecoder.dll small memory leaking problem.
We are using IntelQuickSyncDecoder.dll decording video content by LAVfilter https://code.google.com/p/lavfilters/. there is always a small mount of memory leaking in QuickSyncDecoder.
By Dr.memory tools there are memory leaking report:
Error #1: LEAK 24 direct bytes 0x02f8f530-0x02f8f548 + 536 indirect bytes
# 0 replace_RtlAllocateHeap
# 1 libmfxhw32.dll!MFXVideoVPP_GetVPPStat+0x30b124 (0x059eb435 <libmfxhw32.dll+0x32b435>)
# 2 libmfxhw32.dll!MFXVideoVPP_GetVPPStat+0x30b33e (0x059eb64f <libmfxhw32.dll+0x32b64f>)
# 3 libmfxhw32.dll!MFXVideoVPP_GetVPPStat+0x10528b (0x057e559c <libmfxhw32.dll+0x12559c>)
# 4 libmfxhw32.dll!MFXVideoVPP_GetVPPStat+0x10a397 (0x057ea6a8 <libmfxhw32.dll+0x12a6a8>)
# 5 libmfxhw32.dll!MFXVideoVPP_GetVPPStat+0x10507c (0x057e538d <libmfxhw32.dll+0x12538d>)
# 6 libmfxhw32.dll!MFXVideoVPP_GetVPPStat+0x62b53 (0x05742e64 <libmfxhw32.dll+0x82e64>)
# 7 libmfxhw32.dll!MFXVideoDECODE_Init +0x155 (0x056da226 <libmfxhw32.dll+0x1a226>)
# 8 IntelQuickSyncDecoder.dll!getVersion +0x1093 (0x502a7e34 <IntelQuickSyncDecoder.dll+0x7e34>)
# 9 IntelQuickSyncDecoder.dll!getVersion +0x51f2 (0x502abf93 <IntelQuickSyncDecoder.dll+0xbf93>)
#10 zVideoDecoderd.dll!CDecBase::Decode
There is no getVersion call in the client code, my guess is there is a getVersion call IntelQuickSyncDecoder.dll but not free that memory.
![](/skins/images/B7BA37F9CE4B52FF7CAE1FB0388839C8/responsive_peak/images/icon_anonymous_message.png)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page