[vtk-developers] VTK_DEBUG_LEAKS

[Moreland, Kenneth]

Because that would be insane.  I always turn on VTK_DEBUG_LEAKS in my development builds (and I highly encourage anyone developing with VTK to do the same).  Always having this code enabled would mean I would get a ridiculous amount of stack traces whenever I ran anything.

This is a handy tool when you are looking for a specific problem.  If you have not identified any problem, it just serves to hide anything important.

-Ken


On 1/20/10 8:07 AM, "Arnaud Gelas" <Arnaud_Gelas at hms.harvard.edu> wrote:

Hi Pat,

Sorry for the late reply, I was out of town...

This sounds great! I'll give it a try!

I was wondering why not adding/enabling this code when VTK_DEBUG_LEAKS is ON, and user uses gcc?

Thanks,
Arnaud

On Jan 18, 2010, at 7:07 PM, pat marion wrote:

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 <http://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







   ****      Kenneth Moreland
    ***      Sandia National Laboratories
***********
*** *** ***  email: kmorel at sandia.gov
**  ***  **  phone: (505) 844-8919
    ***      web:   http://www.cs.unm.edu/~kmorel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20100120/912a5997/attachment.html>