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

[Williams, Norman K]

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.
________________________________