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

[David Cole]

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