[vtk-developers] VTK_DEBUG_LEAKS
pat marion
pat.marion at kitware.com
Wed Jan 20 11:01:28 EST 2010
If you know which class you are looking for, you could modify the
vtkObjectBaseBacktrace function so that it filters by class name (the char*
type argument), but just be aware that when vtkObjectBaseBacktrace is called
from object constructors the class name is not known.
Pat
On Wed, Jan 20, 2010 at 10:55 AM, Arnaud Gelas <Arnaud_Gelas at hms.harvard.edu
> wrote:
> I have just started one application with this piece of code, and I see what
> you mean by "ridiculous amount of stack traces"...
>
> You're right, you need to first identify the problem before using it...
>
> Arnaud
>
> On Jan 20, 2010, at 10:21 AM, Moreland, Kenneth wrote:
>
> 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<http://www.cs.unm.edu/%7Ekmorel>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20100120/50290813/attachment.html>
More information about the vtk-developers
mailing list