Memory leak and buffer overrun detection code in VC7.1

  • Thread starter Thread starter Senapathy
  • Start date Start date
S

Senapathy

Environment: WinXP, VC++ 7.1 Standard Edition
~~~~~~~~~~~

I have a set of functions that I invoke from main() function of a sample
console app.
These are the functions:
_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );
HANDLE hLogFile = CreateFile(_T("D:\\Temp\\dump.txt"),
GENERIC_WRITE|GENERIC_READ,0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL,
NULL);

_CrtSetReportMode(_CRT_WARN, _CRTDBG_MODE_FILE);

_CrtSetReportFile(_CRT_WARN, hLogFile);

_CrtSetReportMode(_CRT_ERROR, _CRTDBG_MODE_FILE);

_CrtSetReportFile(_CRT_ERROR, hLogFile);


These are supposed to catch memory leaks and array bounds overflow etc and
then dump the data into the designated text file.

My console app is built with /RTC1 ( = /RTCsu ) flag to detect stack /
buffer overflows.

Now if I introduce a buffer overflow (accessing over last element of a C
style array), the error is properly redirected to the text file and I can
see the results in the txt file.

Problem:
---------
Obviously, I have many such exes where I wish to introduce this run time
debug checks. So the idea was to have a common dll which everyone uses and
then put these calls from within the DllMain of the dll. So if any exe just
links against this dll, it automatically has called these functions through
the DllMain.

I coded these functions in the PROCESS_ATTACH part of the common dll. When
the exe runs, I can see that the DllMain and these functions are getting
called. However, now when the program terminates, there is no dump
generated.

I can see that one thing: if the leak is in main() module, the check
functions have to be called from there.
If the leak / overflow is there in the Dll, the calls have to be made from
within the Dll.

Is there any way in which I can make the call within the Dll and not expect
every exe to also change?
 
Jochen Kalmbach said:
You need to link against the DLL-Version of the CRT! (both the EXE and the
DLL).
Click to expand...

Sorry, I didnt quite understand what you meant. Do you mean that I should
explicitly link against MSVCR71.dll explicitly? (in the linker settings)
 
Senapathy said:
Sorry, I didnt quite understand what you meant. Do you mean that I should
explicitly link against MSVCR71.dll explicitly? (in the linker settings)
Click to expand...

I mean that you should go into your project settings (C/C++ | Code
generation) and change the entry
"Runtime library" to "Multi-Threaded (Debug) DLL (/MD(d))"

If you are using the MFC you also need to change the same stuff for the
MFC-settings (general-page: "Use MFC in a shared DLL").

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/
 
I am beyond words to express my thanks !
Your solution is perfect ! So simple and yet the exact answer that I was
looking for.

Thank you so much for sharing the knowledge with me!!!

Btw, just out of curiosity - from where did you get this information? From
sheer experience or from some documentation?
Reason I am asking is: in the MSDN documentation for the _CrtSetxx
functions, it is not documented that it should be done this way...

Regards,
Sena
 
Senapathy said:
I am beyond words to express my thanks !
Your solution is perfect ! So simple and yet the exact answer that I
was looking for.

Thank you so much for sharing the knowledge with me!!!

Btw, just out of curiosity - from where did you get this information?
From sheer experience or from some documentation?
Reason I am asking is: in the MSDN documentation for the _CrtSetxx
functions, it is not documented that it should be done this way...
Click to expand...

If you don't link everything against the DLL version of the runtime, then
you have multiple versions of the runtime in the resulting process. Setting
the error mode (etc) for the runtime in the DLL has no effect on the other
runtime image(s) that are loaded in the process.

As a general rule, if you need to share runtime state across modules, you
need to link everything with the DLL runtime library. Runtime state
includes global settings (like you experienced), FILE* values, memory
allocations, C "file handles" (not to be confused with operating system
HANDLEs) and probably a few other things that I'm missing at the moment :)
Note that any sharing of C++ standard library components involves sharing of
memory allocations, so if you want to pass a std::vector from an EXE to a
DLL, they should both be linked to the DLL runtime library.

-cd
 
Back
Top