[vtk-developers] VTK_DEBUG_LEAKS

[Arnaud Gelas]

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
>
> 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/20100120/794cc404/attachment.html>