Changes between Version 4 and Version 5 of OsgDebugging

Timestamp:

Aug 3, 2010, 8:42:18 PM (14 years ago)

Author:

Torben Dannhauer

Comment:

--

OsgDebugging

@@ -3 +3 @@
 = Short Introduction to Debugging and Hunting Memory Leaks on Windows and Linux =
 
-Debugging the application for memory leak is quite easy. This indroduction adressess debugging beginners but assumes your are familiar with basic debugging techniques (stop and go, watching values..)
+This indroduction adresses beginners but assumes they are familiar at least with basic debugging techniques (stop and go, watching values..). If you are searching for advanced tips, please use the MSDN and Valgrind documentation.
 
 == Windows ==
 
-The windows debugging how to is based on Microsoft Visual Studio 2008 Professional. Using another MSVC Version should be possible without modification. Should... :)
+The windows debugging !HowTo is based on Microsoft Visual Studio 2008 Professional. Using another MSVC Version should be possible without modification. ...should... :)
 
-The standart program debugging regarding software errors is easy: 
- * On Crashes: Start the software with the debugger, use it until it crashes. The debugger will stop and you can go back at the call stack and look for the first function located in your programm. This function is your first approach to search for your error :)
- * On program logic errors without crash: Place debug messages in your code, and set breakpoints at interesting lines so you can watch variable values when the debugger break at that points.
+In debug builds MSVC outputs memoryleaks automatically. Unfortunately the message do not contain filenames or line numbers but only lost bytes by default. Additionally MSVC stops the memory accounting to early, so the satic elements of OSG are not freed already and result in a lot of false memory leak reports. This behaviour can only be correct with crude workarounds like linking to MFC or similar.
 
-=== Memory Leak Debugging ===
-While MSVC outputs memoryleaks automatically. it is very hard to modify it's behaviour to get useful leak reports.
+At least MSVC can be configured to report all memory leaks inside the source files with filenames and line numbers to a output file. This allows to identify some of the "true" memory leaks and correct hem already on the windows platform.
 
-What do wo want? A report of every leak with the following information
-* Filename whre the leak was caused.
-* Function name where the leak was caused.
-* Linenumer where the leak was caused.
+'''The best practice on windows is to use MSVC to eliminate all obvious memory leaks and to continue with Valgrind on Linux for final checks'''
 
-todo: how to modify sourcecode to get the informations.
+What do we need to hunt the memory leaks? A report of every leak with the following information
+ * Filename whre the leak was caused.
+ * Function name where the leak was caused.
+ * Line number where the leak was caused.
 
-pre main()
+To achieve this, we have to perform two steps:
+ * Manipulation main.cpp to start memory leak detection
+ * Adding some definitions to each source file to replace the new operator with a debug version which outputs the requiered information.
+
+=== main.cpp ===
+To enable the debug memory allocation, the following codelines are required '''before''' the main function:
 {{{
 #!cpp
@@ -36 +38 @@
 }}}
 
-Inside main()
+Inside the main() function wo have to specify in detail how to track the memory. Because the MSVC debug windows is quite slow for large outputs, we use the file output:
 {{{
 #!cpp
 #ifdef _DEBUG
         #ifdef WIN32
-                #include <leakDetection.h>      // for main: must be inside function. In classes: headerfile inside calss is sufficient
+                #include <leakDetection.h>      // Must be inside main function. In classes: headerfile inside class is sufficient
                 int tmp_flag;