[Insight-developers] Circular smart pointer references causing memory leaks

[Bill Lorensen]

Information does not die on the wiki, it just hides.

On Thu, Aug 4, 2011 at 12:28 PM, Williams, Norman K <
norman-k-williams at uiowa.edu> wrote:

> Once I understood the problem, and thought about it for a minute that is
> indeed what I concluded as well.  Furthermore it should have been
> self-evident.
>
>
> This is the sort of implicit design stricture that would be great if it
> was made explicit somewhere. I'd write it up for the Wiki, but I'm
> beginning to thing that Wikis are where good information goes to die.
> Maybe we need a 'finer points of ITK programming'
> document/blog/webpage/wiki/something?
>
> On 8/4/11 11:07 AM, "David Cole" <david.cole at kitware.com> wrote:
>
> >Don't do that is definitely the right answer.
> >
> >If there is a cycle, then:
> >- one of them should not be a smart pointer
> >    OR
> >- code should exist to explicitly break the cycle prior to the destructor
> >
> >You should only use a smart pointer on the side of the relationship
> >that "owns" the related object. If the owned object needs a pointer
> >back to its owner, then it should not be a smart pointer.
> >
> >
> >David C.
> >
> >
> >On Thu, Aug 4, 2011 at 11:51 AM, Bill Lorensen <bill.lorensen at gmail.com>
> >wrote:
> >> I vote for "don't do that". Seems like a design flaw.
> >>
> >> On Thu, Aug 4, 2011 at 11:40 AM, Williams, Norman K
> >> <norman-k-williams at uiowa.edu> wrote:
> >>>
> >>> Vince figured this out and solved one leak, but it points to something
> >>> that I didn't think about that needs to be guarded against.
> >>>
> >>>
> >>> class A contains a SmartPointer to instance of class B
> >>> class B contains a SmartPointer to instance of class A
> >>>
> >>> Whoever wrote A & B thought that the destructors of instances of A & B
> >>> would in turn call the destructors for the smart pointers, and
> >>>eventually,
> >>> the instances of A & B would all be freed when no smart pointers to
> >>>them
> >>> went out of scope.
> >>>
> >>> But this isn't the case and here's why: Even after all third party
> >>> SmartPointers to A & B go out of scope, the instances of A & B will
> >>>still
> >>> have a reference count of 1, so the destructors will never get called,
> >>>and
> >>> the smart pointer members will live forever.
> >>>
> >>> The only solution, apparently, is that there needs to be a
> >>>Pre-destructor
> >>> that clears all smart pointers in the class, that gets called before
> >>>all
> >>> the smart pointers to an object go out of scope or get re-assigned.
> >>>
> >>> Now, in general, this isn't a problem, but the FEM code is a multiple
> >>> interconnected cyclic graphs of smart pointer references. Knowing that
> >>>I
> >>> can begin to try and fix it.
> >>>
> >>> But it points up a weakness in ITK's dependence on Smart Pointers.
> >>>Even
> >>> though in most cases, it solves memory allocation issues; in others
> >>>it's a
> >>> nightmare, where letting a SmartPointer to an object go out of scope
> >>> actually makes the object pointed to immortal.
> >>>
> >>> Anyone have any ideas how to fix this other than "don't do that!"?
> >>>
> >>>
> >>>
> >>> ________________________________
> >>> Notice: This UI Health Care e-mail (including attachments) is covered
> >>>by
> >>> the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is
> >>> confidential and may be legally privileged.  If you are not the
> >>>intended
> >>> recipient, you are hereby notified that any retention, dissemination,
> >>> distribution, or copying of this communication is strictly prohibited.
> >>>  Please reply to the sender that you have received the message in
> >>>error,
> >>> then delete it.  Thank you.
> >>> ________________________________
> >>> _______________________________________________
> >>> Powered by www.kitware.com
> >>>
> >>> Visit other Kitware open-source projects at
> >>> http://www.kitware.com/opensource/opensource.html
> >>>
> >>> Kitware offers ITK Training Courses, for more information visit:
> >>> http://kitware.com/products/protraining.html
> >>>
> >>> Please keep messages on-topic and check the ITK FAQ at:
> >>> http://www.itk.org/Wiki/ITK_FAQ
> >>>
> >>> Follow this link to subscribe/unsubscribe:
> >>> http://www.itk.org/mailman/listinfo/insight-developers
> >>
> >>
> >> _______________________________________________
> >> Powered by www.kitware.com
> >>
> >> Visit other Kitware open-source projects at
> >> http://www.kitware.com/opensource/opensource.html
> >>
> >> Kitware offers ITK Training Courses, for more information visit:
> >> http://kitware.com/products/protraining.html
> >>
> >> Please keep messages on-topic and check the ITK FAQ at:
> >> http://www.itk.org/Wiki/ITK_FAQ
> >>
> >> Follow this link to subscribe/unsubscribe:
> >> http://www.itk.org/mailman/listinfo/insight-developers
> >>
> >>
>
>
>
> ________________________________
> Notice: This UI Health Care e-mail (including attachments) is covered by
> the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is
> confidential and may be legally privileged.  If you are not the intended
> recipient, you are hereby notified that any retention, dissemination,
> distribution, or copying of this communication is strictly prohibited.
>  Please reply to the sender that you have received the message in error,
> then delete it.  Thank you.
> ________________________________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20110804/ce5f654a/attachment.htm>