When I create a VCL project (C++-Builder XE7 update 1) with MadExcept and memory leak reporting enabled, every time an exception is handled or when type information is requested it results in a memory leak reported by MadExcept. When I use Codeguard instead of MadExcept it does not report these leaks. (I'm compiling in Debug mode).
I'm trying to figure out if these are real leaks, or not. A lot of these leaks a reported for my project, and it not only takes quite some time to generate the leak report each time I close the application, but they also obscure the leaks in my own code I want to find.
For example a new VCL forms application with just a button and a onClick handler with the code below result in three reported leaks when the button is pressed once:
Code: Select all
String name = typeid(int).name();
try
{
throw Exception("Oops");
}
catch(const Exception& E)
{
}
Code: Select all
allocation number: 2075
program up time: 4,08 s
type: GetMem
address: $24d4cd8
size: 28
access rights: read/write
main thread ($89c):
671cc9f6 madExcept32.dll madExceptDbg 1575 GetMemCallback
3207ddeb CC32160MT.DLL _malloc
320705d4 CC32160MT.DLL $bnew
320804d6 CC32160MT.DLL ___VCL_add_EH
320ada62 CC32160MT.DLL ____ExceptionHandler
00404d6c Project2.exe __ExceptionHandler
7794015e ntdll.dll KiUserExceptionDispatcher
320ad3fc CC32160MT.DLL _ThrowExceptionLDTC
00403a6c Project2.exe Unit2.cpp 25 TForm2.Button1Click
505c3183 vcl210.bpl Vcl.Controls 7348 TControl.Click
505c76e2 vcl210.bpl Vcl.Controls 10038 TWinControl.WndProc
505e7c20 vcl210.bpl Vcl.StdCtrls 5163 TButtonControl.WndProc
505c7847 vcl210.bpl Vcl.Controls 10107 DoControlMsg
505c76e2 vcl210.bpl Vcl.Controls 10038 TWinControl.WndProc
5070ce98 vcl210.bpl Vcl.Forms 4427 TCustomForm.WndProc
505c6d1c vcl210.bpl Vcl.Controls 9750 TWinControl.MainWndProc
5016e218 rtl210.bpl System.Classes 16600 StdWndProc
752f96d0 USER32.dll SendMessageW
75300d58 USER32.dll CallWindowProcW
505c77f2 vcl210.bpl Vcl.Controls 10079 TWinControl.DefaultHandler
505c76e2 vcl210.bpl Vcl.Controls 10038 TWinControl.WndProc
505e7c20 vcl210.bpl Vcl.StdCtrls 5163 TButtonControl.WndProc
5016e218 rtl210.bpl System.Classes 16600 StdWndProc
752f7895 USER32.dll DispatchMessageW
5071635b vcl210.bpl Vcl.Forms 10352 TApplication.ProcessMessage
memory dump:
024d4cd8 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
024d4ce8 00 00 00 00 00 00 00 00 - 00 00 00 00 ............
allocation number: 2067
program up time: 4,05 s
type: GetMem
address: $24dc0a0
size: 28
access rights: read/write
main thread ($89c):
671cc9f6 madExcept32.dll madExceptDbg 1575 GetMemCallback
3207ddeb CC32160MT.DLL _malloc
320705d4 CC32160MT.DLL $bnew
320804d6 CC32160MT.DLL ___VCL_add_EH
320ad3fc CC32160MT.DLL _ThrowExceptionLDTC
00403a6c Project2.exe Unit2.cpp 25 TForm2.Button1Click
505c3183 vcl210.bpl Vcl.Controls 7348 TControl.Click
505c76e2 vcl210.bpl Vcl.Controls 10038 TWinControl.WndProc
505e7c20 vcl210.bpl Vcl.StdCtrls 5163 TButtonControl.WndProc
505c7847 vcl210.bpl Vcl.Controls 10107 DoControlMsg
505c76e2 vcl210.bpl Vcl.Controls 10038 TWinControl.WndProc
5070ce98 vcl210.bpl Vcl.Forms 4427 TCustomForm.WndProc
505c6d1c vcl210.bpl Vcl.Controls 9750 TWinControl.MainWndProc
5016e218 rtl210.bpl System.Classes 16600 StdWndProc
752f96d0 USER32.dll SendMessageW
75300d58 USER32.dll CallWindowProcW
505c77f2 vcl210.bpl Vcl.Controls 10079 TWinControl.DefaultHandler
505c76e2 vcl210.bpl Vcl.Controls 10038 TWinControl.WndProc
505e7c20 vcl210.bpl Vcl.StdCtrls 5163 TButtonControl.WndProc
5016e218 rtl210.bpl System.Classes 16600 StdWndProc
752f7895 USER32.dll DispatchMessageW
5071635b vcl210.bpl Vcl.Forms 10352 TApplication.ProcessMessage
memory dump:
024dc0a0 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
024dc0b0 00 00 00 00 00 00 00 00 - 00 00 00 00 ............
allocation number: 2063
program up time: 1,42 s
type: GetMem
address: $250d378
size: 20
access rights: read/write
main thread ($89c):
671cc9f6 madExcept32.dll madExceptDbg 1575 GetMemCallback
3207ddeb CC32160MT.DLL _malloc
320705d4 CC32160MT.DLL $bnew
320ae6f0 CC32160MT.DLL __GetTypeInfo
00403a00 Project2.exe Unit2.cpp 21 TForm2.Button1Click
505c3183 vcl210.bpl Vcl.Controls 7348 TControl.Click
505c76e2 vcl210.bpl Vcl.Controls 10038 TWinControl.WndProc
505e7c20 vcl210.bpl Vcl.StdCtrls 5163 TButtonControl.WndProc
505c7847 vcl210.bpl Vcl.Controls 10107 DoControlMsg
505c76e2 vcl210.bpl Vcl.Controls 10038 TWinControl.WndProc
5070ce98 vcl210.bpl Vcl.Forms 4427 TCustomForm.WndProc
505c6d1c vcl210.bpl Vcl.Controls 9750 TWinControl.MainWndProc
5016e218 rtl210.bpl System.Classes 16600 StdWndProc
752f96d0 USER32.dll SendMessageW
75300d58 USER32.dll CallWindowProcW
505c77f2 vcl210.bpl Vcl.Controls 10079 TWinControl.DefaultHandler
505c76e2 vcl210.bpl Vcl.Controls 10038 TWinControl.WndProc
505e7c20 vcl210.bpl Vcl.StdCtrls 5163 TButtonControl.WndProc
5016e218 rtl210.bpl System.Classes 16600 StdWndProc
752f7895 USER32.dll DispatchMessageW
5071635b vcl210.bpl Vcl.Forms 10352 TApplication.ProcessMessage
memory dump:
0250d378 90 4e 0d 32 a4 3a 40 00 - 00 00 00 00 00 00 00 00 .N.2.:@.........
0250d388 00 00 00 00 ....
I've browsed the Embarcadero source code a bit, and I found some code there that suggests at least the GetTypeInfo leak should not happen.
For example in "C:\Program Files (x86)\Embarcadero\Studio\15.0\source\cpprtl\Source\except\xxtype.cpp" I find the FreeHashTab function:
Code: Select all
// Free the hash memory so that CodeGuard and MemorySleuth don't have a cow.
static void FreeHashTab (void)
{
#pragma exit FreeHashTab 1 /* Finalize the hash memory blocks */
/* This must happen before the heap shuts down */
...
Can you reproduce these results?
Are they real leaks?
Do you have any idea why these leaks are reported by MadExcept and not by CodeGuard?