[vtk-developers] VTK_DEBUG_LEAKS

[pat marion]

Hi,

I don't find valgrind to be very useful for debugging vtk leaks because
valgrind only reports where the memory was allocated.  A vtkObject leaks
because someone holds a reference to it and does not release the reference.
Knowing where the object was allocated doesn't necessarily give you any
clues.

Here is a patch by Brad King that will print a stack trace each time a
vtkObject's reference count is increased or decreased.  The output is very
verbose, but if you know what you are looking for this can give you the
clues you need to track down the leak-

Brad King on 12/23/09-

This hacks up vtkObjectBase to report a stack trace (on Linux) for every
constructor, Register, or UnRegister call on VTK objects.  We include
the object address (pointer value) for identification.  While very
verbose, the output produced with this change can be used to find the
source of leaked objects.
---
 Common/vtkObjectBase.cxx |   27 +++++++++++++++++++++++++++
 1 files changed, 27 insertions(+), 0 deletions(-)

diff --git a/Common/vtkObjectBase.cxx b/Common/vtkObjectBase.cxx
index de8c1cf..1b71fb7 100644
--- a/Common/vtkObjectBase.cxx
+++ b/Common/vtkObjectBase.cxx
@@ -19,6 +19,10 @@

 #include <vtksys/ios/sstream>

+static inline
+void vtkObjectBaseBacktrace(
vtkObjectBase* obj, const char* op,
+                            const char* type);
+
 #define vtkBaseDebugMacro(x)

 class vtkObjectBaseToGarbageCollectorFriendship
@@ -63,6 +67,7 @@ ostream& operator<<(ostream& os, vtkObjectBase& o)
 // to zero.
 vtkObjectBase::vtkObjectBase()
 {
+  vtkObjectBaseBacktrace(this, "Construct", "vtkObjectBase");
  this->ReferenceCount = 1;
  // initial reference count = 1 and reference counting on.
 }
@@ -229,6 +234,7 @@ void vtkObjectBase::PrintRevisions(ostream& os)
 //----------------------------------------------------------------------------
 void vtkObjectBase::RegisterInternal(vtkObjectBase*, int check)
 {
+  vtkObjectBaseBacktrace(this, "Register", this->GetClassName());
  // If a reference is available from the garbage collector, use it.
  // Otherwise create a new reference by incrementing the reference
  // count.
@@ -242,6 +248,7 @@ void vtkObjectBase::RegisterInternal(vtkObjectBase*, int
check)
 //----------------------------------------------------------------------------
 void vtkObjectBase::UnRegisterInternal(vtkObjectBase*, int check)
 {
+  vtkObjectBaseBacktrace(this, "UnRegister", this->GetClassName());
  // If the garbage collector accepts a reference, do not decrement
  // the count.
  if(check && this->ReferenceCount > 1 &&
@@ -274,3 +281,23 @@ void
vtkObjectBase::ReportReferences(vtkGarbageCollector*)
 {
  // vtkObjectBase has no references to report.
 }
+
+//----------------------------------------------------------------------------
+#include <execinfo.h>
+static inline
+void vtkObjectBaseBacktrace(vtkObjectBase* obj, const char* op,
+                            const char* type)
+{
+  static const int max_depth = 100;
+  void* calls[max_depth];
+  int depth = backtrace(calls, max_depth);
+  if(char** symbols = backtrace_symbols(calls, depth))
+    {
+    fprintf(stderr, "%s %p %s\n", op, obj, type);
+    for(int i = 0; i < depth; ++i)
+      {
+      fprintf(stderr, "  %s\n", symbols[i]);
+      }
+    free(symbols);
+    }
+}


On Fri, Jan 15, 2010 at 9:23 AM, Mathieu Malaterre <
mathieu.malaterre at gmail.com> wrote:

> On Thu, Jan 14, 2010 at 11:50 PM, Arnaud Gelas
> <arnaud_gelas at hms.harvard.edu> wrote:
> > Hi Guys,
> >
> > I really liked the idea of VTK_DEBUG_LEAKS to know exactly which objects
> > were not deleted (name of objects forgot to be deleted and number of
> > instances)
> > But the way it is right now it is quite difficult to get a clue on WHERE
> we
> > forgot to delete (maybe due to the lack of hierarchical information?).
> >
> > Is there anyway to improve it by adding some additional information to
> track
> > where leaks exactly come from?
>
> I usually sort them by count number. The idea is that if a vtk object
> with a count of 1 remains, it 'most of the time' means this is the
> toplevel vtk object that uses others.
>
> If you are a C#/Java/C++0xWithGarbageCollector guy, then simply switch
> to vtkSmartPointer<> coding style convention.
>
> 2cts
> --
> Mathieu
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://www.vtk.org/mailman/listinfo/vtk-developers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20100118/6f44d979/attachment.html>