Changes between Version 3 and Version 4 of OsgDebugging

Timestamp:

Aug 3, 2010, 8:39:28 AM (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 is quite easy. This indroduction assumes your are familiar with basic debugging techniques (stop and go, watching values..)
-Because debugging large programs is very slow, debug osgvisual only with small databases. Often, it is even sufficient to debug osgVisual without any terrain database loaded. 
+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..)
 
 == Windows ==
@@ -90 +89 @@
 todo: false positives
 
-Set your brakpoints, 
+Set your breakpoints, 
 
 == Linux ==
 
+To debug osgVisual on Linux, be sure you have compiled and installed OSG with debug symbols (It is not interfering with the release build). Build osgVisual as Debug (osgVisuald) and start it with valgrind:
 {{{
 #!sh
-valgrind --error-limit=no --leak-check=full ./osgVisuald -m /path/to/database.ive -p yourPath.path
+valgrind --error-limit=no --leak-check=full ./osgVisuald <yourParameters> /path/to/database.ive
 }}}
+
+In the output, Valgrind will output errors in osgVisual as well as in involved system libraries like libGL or X11.
+
+For memory leaks, the "Heap Summary" is very interesting. Here Valgrin lists all possible and sure memory loss. For each incident it lists a call stack to allow to follow the program path over 10 steps to the function the memory loss happens. For all libraries with debug build, it also shows the line number, so it is quite easy to identify the relevant code. The following example shows a memory leak at the heap:
+{{{
+==4281== HEAP SUMMARY:                                                                                                                                                                                                                                                                                                      
+==4281==    in use at exit: 32,183 bytes in 413 blocks                                                                                                                                                                                                                                                                     
+==4281==   total heap usage: 3,086,029 allocs, 3,085,616 frees, 1,582,088,128 bytes allocated                                                                                                                                                                                                                               
+==4281==
+
+...
+
+==4281== 128 (24 direct, 104 indirect) bytes in 1 blocks are definitely lost in loss record 52 of 77
+==4281==    at 0x4C2596C: operator new(unsigned long) (vg_replace_malloc.c:220)
+==4281==    by 0x6F85405: __gnu_cxx::new_allocator<std::_List_node<osg::ref_ptr<osg::Texture::TextureObject> > >::allocate(unsigned long, void const*) (new_allocator.h:89)
+==4281==    by 0x6F8411D: std::_List_base<osg::ref_ptr<osg::Texture::TextureObject>, std::allocator<osg::ref_ptr<osg::Texture::TextureObject> > >::_M_get_node() (stl_list.h:316)
+==4281==    by 0x6F834BE: std::list<osg::ref_ptr<osg::Texture::TextureObject>, std::allocator<osg::ref_ptr<osg::Texture::TextureObject> > >::_M_create_node(osg::ref_ptr<osg::Texture::TextureObject> const&) (stl_list.h:461)
+==4281==    by 0x6F828AE: std::list<osg::ref_ptr<osg::Texture::TextureObject>, std::allocator<osg::ref_ptr<osg::Texture::TextureObject> > >::_M_insert(std::_List_iterator<osg::ref_ptr<osg::Texture::TextureObject> >, osg::ref_ptr<osg::Texture::TextureObject> const&) (stl_list.h:1407)
+==4281==    by 0x6F81831: std::list<osg::ref_ptr<osg::Texture::TextureObject>, std::allocator<osg::ref_ptr<osg::Texture::TextureObject> > >::push_back(osg::ref_ptr<osg::Texture::TextureObject> const&) (stl_list.h:920)
+==4281==    by 0x6F7A638: osg::Texture::TextureObjectSet::orphan(osg::Texture::TextureObject*) (Texture.cpp:641)
+==4281==    by 0x6F7B14F: osg::Texture::TextureObjectManager::releaseTextureObject(osg::Texture::TextureObject*) (Texture.cpp:839)
+==4281==    by 0x6F7B89F: osg::Texture::releaseTextureObject(unsigned int, osg::Texture::TextureObject*) (Texture.cpp:930)
+==4281==    by 0x6F7D104: osg::Texture::dirtyTextureObject() (Texture.cpp:1103)
+==4281==    by 0x6F7C2CA: osg::Texture::~Texture() (Texture.cpp:991)
+==4281==    by 0x6F719C4: osg::Texture2D::~Texture2D() (Texture2D.cpp:50)
+
+...
+
+==4281== LEAK SUMMARY:
+==4281==    definitely lost: 432 bytes in 6 blocks
+==4281==    indirectly lost: 208 bytes in 2 blocks
+==4281==      possibly lost: 0 bytes in 0 blocks
+==4281==    still reachable: 31,223 bytes in 404 blocks
+==4281==         suppressed: 0 bytes in 0 blocks
+==4281== Reachable blocks (those to which a pointer was found) are not shown.
+==4281== To see them, rerun with: --leak-check=full --show-reachable=yes
+==4281==
+==4281== For counts of detected and suppressed errors, rerun with: -v
+==4281== ERROR SUMMARY: 692992 errors from 2368 contexts (suppressed: 7 from 7)
+}}}
+
+
+== Tips & Troubleshooting ==
+
+ * Because debugging large programs is very slow, debug osgVisual only with small databases. Sometimes, it is even sufficient to debug osgVisual without any terrain database loaded.