Could shared_ptr cause memory leak?

older
Re: [boost] [multi_index] problem...

hh h

3 Jan 2019 3 Jan '19

7:25 p.m.

Suppose I have a session object A, the shared_ptr<A> is created and stored in a global connection list after a connection is accepted by async_accept, when the connection is terminated, the reference in connection list is removed, but since A has a member B still holds A reference, that session object is never deleted, is it memory leak? class A : public boost::enable_shared_from_this<A> { public: A(); ~A(); void Start() {b = make_shared(shared_from_this());} void Stop(); private: shared_ptr b; };

Show replies by date

Josh Juran

3 Jan 3 Jan

8:15 p.m.

On Jan 3, 2019, at 2:25 PM, hh h via Boost wrote:

...

Suppose I have a session object A, the shared_ptr<A> is created and stored in a global connection list after a connection is accepted by async_accept, when the connection is terminated, the reference in connection list is removed, but since A has a member B still holds A reference, that session object is never deleted, is it memory leak?

class A : public boost::enable_shared_from_this<A> { public: A(); ~A(); void Start() {b = make_shared(shared_from_this());} void Stop(); private: shared_ptr b; };

Yes, what you describe is a resource leak due to a reference loop foiling shared_ptr's RAII reference counting. There are several ways to remedy this, one of which is to use a weak_ptr for one of the references. Higher-risk options include making sure to break the reference loop manually, or using a raw pointer instead. Josh

hh h

9:27 p.m.

Thanks Josh, just wandering why the shared_ptr does not have a dereference function? Looks the only way to break the reference loop manually is calling b.reset() which might cause other implication, I am going to use a raw pointer. Never use shared_from_this to its own members. On 1/4/19, Josh Juran via Boost wrote:

...

On Jan 3, 2019, at 2:25 PM, hh h via Boost wrote:

...
Suppose I have a session object A, the shared_ptr<A> is created and stored in a global connection list after a connection is accepted by async_accept, when the connection is terminated, the reference in connection list is removed, but since A has a member B still holds A reference, that session object is never deleted, is it memory leak?

class A : public boost::enable_shared_from_this<A> { public: A(); ~A(); void Start() {b = make_shared(shared_from_this());} void Stop(); private: shared_ptr b; };

Yes, what you describe is a resource leak due to a reference loop foiling shared_ptr's RAII reference counting.

There are several ways to remedy this, one of which is to use a weak_ptr for one of the references. Higher-risk options include making sure to break the reference loop manually, or using a raw pointer instead.

Josh

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Michael Caisse

10:14 p.m.

On 1/3/19 11:25, hh h via Boost wrote:

...

Suppose I have a session object A, the shared_ptr<A> is created and stored in a global connection list after a connection is accepted by async_accept, when the connection is terminated, the reference in connection list is removed, but since A has a member B still holds A reference, that session object is never deleted, is it memory leak?

class A : public boost::enable_shared_from_this<A> { public: A(); ~A(); void Start() {b = make_shared(shared_from_this());} void Stop(); private: shared_ptr b; };

What are you trying to achieve with the above? The construct says B has shared ownership of an A thing. Or do you want to 'use' an A thing? -- Michael Caisse Ciere Consulting ciere.com

hh h

11:35 p.m.

Yes, B can access A functions On 1/4/19, Michael Caisse via Boost wrote:

...

On 1/3/19 11:25, hh h via Boost wrote:

...
Suppose I have a session object A, the shared_ptr<A> is created and stored in a global connection list after a connection is accepted by async_accept, when the connection is terminated, the reference in connection list is removed, but since A has a member B still holds A reference, that session object is never deleted, is it memory leak?

class A : public boost::enable_shared_from_this<A> { public: A(); ~A(); void Start() {b = make_shared(shared_from_this());} void Stop(); private: shared_ptr b; };

What are you trying to achieve with the above? The construct says B has shared ownership of an A thing. Or do you want to 'use' an A thing?

-- Michael Caisse Ciere Consulting ciere.com

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Michael Caisse

4 Jan 4 Jan

12:16 a.m.

Please do not top-post: https://www.boost.org/community/policy.html#quoting

...

On 1/4/19, Michael Caisse via Boost wrote:

...
On 1/3/19 11:25, hh h via Boost wrote:

...
Suppose I have a session object A, the shared_ptr<A> is created and stored in a global connection list after a connection is accepted by async_accept, when the connection is terminated, the reference in connection list is removed, but since A has a member B still holds A reference, that session object is never deleted, is it memory leak?

class A : public boost::enable_shared_from_this<A> { public: A(); ~A(); void Start() {b = make_shared(shared_from_this());} void Stop(); private: shared_ptr b; };

What are you trying to achieve with the above? The construct says B has shared ownership of an A thing. Or do you want to 'use' an A thing?

On 1/3/19 15:35, hh h wrote:> Yes, B can access A functions

A shared_ptr denotes shared ownership. Don't use the shared pointer in B if it is a usage pattern and not an ownership pattern. Pass a raw pointer or reference instead. Also, does `b` have shared ownership in the thing above? If not, it should be a unique_ptr. -- Michael Caisse Ciere Consulting ciere.com

hh h

6:57 a.m.

Sorry, unaware of the google quick reply checked quoted text by default. Yep, using a raw pointer works perfect. Thanks Michael.

2137

Age (days ago)

2138

Last active (days ago)

List overview

Download

6 comments

3 participants

participants (3)

hh h
Josh Juran
Michael Caisse