Hi,<br><br>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.<br>
<br>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-<br>
<br>Brad King on 12/23/09-<br><br>This hacks up vtkObjectBase to report a stack trace (on Linux) for every<br>
constructor, Register, or UnRegister call on VTK objects. We include<br>
the object address (pointer value) for identification. While very<br>
verbose, the output produced with this change can be used to find the<br>
source of leaked objects.<br>
---<br>
Common/vtkObjectBase.cxx | 27 +++++++++++++++++++++++++++<br>
1 files changed, 27 insertions(+), 0 deletions(-)<br>
<br>
diff --git a/Common/vtkObjectBase.cxx b/Common/vtkObjectBase.cxx<br>
index de8c1cf..1b71fb7 100644<br>
--- a/Common/vtkObjectBase.cxx<br>
+++ b/Common/vtkObjectBase.cxx<br>
@@ -19,6 +19,10 @@<br>
<br>
#include <vtksys/ios/sstream><br>
<br>
+static inline<br>
+void vtkObjectBaseBacktrace(<div id=":4c" class="ii gt">vtkObjectBase* obj, const char* op,<br>
+ const char* type);<br>
+<br>
#define vtkBaseDebugMacro(x)<br>
<br>
class vtkObjectBaseToGarbageCollectorFriendship<br>
@@ -63,6 +67,7 @@ ostream& operator<<(ostream& os, vtkObjectBase& o)<br>
// to zero.<br>
vtkObjectBase::vtkObjectBase()<br>
{<br>
+ vtkObjectBaseBacktrace(this, "Construct", "vtkObjectBase");<br>
this->ReferenceCount = 1;<br>
// initial reference count = 1 and reference counting on.<br>
}<br>
@@ -229,6 +234,7 @@ void vtkObjectBase::PrintRevisions(ostream& os)<br>
//----------------------------------------------------------------------------<br>
void vtkObjectBase::RegisterInternal(vtkObjectBase*, int check)<br>
{<br>
+ vtkObjectBaseBacktrace(this, "Register", this->GetClassName());<br>
// If a reference is available from the garbage collector, use it.<br>
// Otherwise create a new reference by incrementing the reference<br>
// count.<br>
@@ -242,6 +248,7 @@ void vtkObjectBase::RegisterInternal(vtkObjectBase*, int check)<br>
//----------------------------------------------------------------------------<br>
void vtkObjectBase::UnRegisterInternal(vtkObjectBase*, int check)<br>
{<br>
+ vtkObjectBaseBacktrace(this, "UnRegister", this->GetClassName());<br>
// If the garbage collector accepts a reference, do not decrement<br>
// the count.<br>
if(check && this->ReferenceCount > 1 &&<br>
@@ -274,3 +281,23 @@ void vtkObjectBase::ReportReferences(vtkGarbageCollector*)<br>
{<br>
// vtkObjectBase has no references to report.<br>
}<br>
+<br>
+//----------------------------------------------------------------------------<br>
+#include <execinfo.h><br>
+static inline<br>
+void vtkObjectBaseBacktrace(vtkObjectBase* obj, const char* op,<br>
+ const char* type)<br>
+{<br>
+ static const int max_depth = 100;<br>
+ void* calls[max_depth];<br>
+ int depth = backtrace(calls, max_depth);<br>
+ if(char** symbols = backtrace_symbols(calls, depth))<br>
+ {<br>
+ fprintf(stderr, "%s %p %s\n", op, obj, type);<br>
+ for(int i = 0; i < depth; ++i)<br>
+ {<br>
+ fprintf(stderr, " %s\n", symbols[i]);<br>
+ }<br>
+ free(symbols);<br>
+ }<br>
+}</div><br><br><div class="gmail_quote">On Fri, Jan 15, 2010 at 9:23 AM, Mathieu Malaterre <span dir="ltr"><<a href="mailto:mathieu.malaterre@gmail.com">mathieu.malaterre@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Thu, Jan 14, 2010 at 11:50 PM, Arnaud Gelas<br>
<div class="im"><<a href="mailto:arnaud_gelas@hms.harvard.edu">arnaud_gelas@hms.harvard.edu</a>> wrote:<br>
</div><div class="im">> Hi Guys,<br>
><br>
> I really liked the idea of VTK_DEBUG_LEAKS to know exactly which objects<br>
> were not deleted (name of objects forgot to be deleted and number of<br>
> instances)<br>
> But the way it is right now it is quite difficult to get a clue on WHERE we<br>
> forgot to delete (maybe due to the lack of hierarchical information?).<br>
><br>
> Is there anyway to improve it by adding some additional information to track<br>
> where leaks exactly come from?<br>
<br>
</div>I usually sort them by count number. The idea is that if a vtk object<br>
with a count of 1 remains, it 'most of the time' means this is the<br>
toplevel vtk object that uses others.<br>
<br>
If you are a C#/Java/C++0xWithGarbageCollector guy, then simply switch<br>
to vtkSmartPointer<> coding style convention.<br>
<br>
2cts<br>
--<br>
<font color="#888888">Mathieu<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.vtk.org/mailman/listinfo/vtk-developers" target="_blank">http://www.vtk.org/mailman/listinfo/vtk-developers</a><br>
<br>
</div></div></blockquote></div><br>