shared_ptr memory leak
Dear all, we managed to create a shared_ptr memory leak, without making a cycle. Granted it is highly controversial case. One has to make call in the destructor of the owned object which loops back to the point of assignment. Is this something for the documentation, or may this indeed be flagged as a 'nut' case. Code below is a simplified example, the production case was with some kind of change manager which notification bounced back to the point of assignment. One has to split out header and cpp to get it compilable. void TestSharedPtrLeak() { //make the leak KTestBoostHlpSpLeakParent leak; leak.Reset(false); } //ktestboosthlpspleakparent.h struct KTestBoostHlpSpLeakParent { KTestBoostHlpSpLeakParent(); void Reset(bool b); boost::shared_ptr<KTestBoostHlpSpLeak> m_ptr; }; //ktestboosthlpspleakparent.cpp KTestBoostHlpSpLeakParent::KTestBoostHlpSpLeakParent() { Reset(true); } void KTestBoostHlpSpLeakParent::Reset(bool b) { boost::shared_ptr<KTestBoostHlpSpLeak> ptr(new KTestBoostHlpSpLeak(this, b)); m_ptr = ptr; //m_ptr.swap(ptr); //would solve it btw } //ktestboosthlpspleak.h struct KTestBoostHlpSpLeak { KTestBoostHlpSpLeak(KTestBoostHlpSpLeakParent* p, bool b); ~KTestBoostHlpSpLeak(); public: KTestBoostHlpSpLeakParent* m_p; bool m_b; }; //ktestboosthlpspleak.cpp KTestBoostHlpSpLeak::KTestBoostHlpSpLeak(KTestBoostHlpSpLeakParent* p, bool b) : m_p(p) , m_b(b) { } KTestBoostHlpSpLeak::~KTestBoostHlpSpLeak() { if (m_b) { //recursive call m_p->Reset(false); } }
The case seems entered by Peter Dimov as bug entry: https://svn.boost.org/trac/boost/ticket/2813
gast128:
The case seems entered by Peter Dimov as bug entry:
Yes, I consider this a bug. This is the test I've come up with:
#include
participants (2)
-
gast128
-
Peter Dimov