Re: [Boost-bugs] [Boost C++ Libraries] #12220: Memory leak in future::then()

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #12220: Memory leak in future::then()
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2016-07-13 10:45:47

#12220: Memory leak in future::then()
-------------------------------+-------------------------------------
  Reporter:  valentin.milea@…  |      Owner:  anthonyw
      Type:  Bugs              |     Status:  new
 Milestone:  To Be Determined  |  Component:  thread
   Version:  Boost 1.61.0      |   Severity:  Regression
Resolution:                    |   Keywords:  memory leak future then
-------------------------------+-------------------------------------

Comment (by Bloody Rookie):

 I can confirm that for the mentioned Boost versions there is a problem
 with the lifetime of a future continuation.
 In Boost 1.60 the flag BOOST_THREAD_FUTURE_BLOCKING was introduced. For
 future continuations with async launch policy the flag is used in the
 future.hpp code in the following way:

 {{{
 #ifdef BOOST_THREAD_FUTURE_BLOCKING
              this->thr_ = thread(&future_async_shared_state::run,
 static_shared_from_this(this), boost::forward<Fp>(f));
 #else
             thread(&future_async_shared_state::run,
 static_shared_from_this(this), boost::forward<Fp>(f)).detach();
 #endif
 }}}

 If the flag is defined the thread is attached to the
 future_async_shared_state via the thr_ member variable. The thread holds a
 reference to the shared state in its thread_info member (note the
 static_shared_from_this(this) parameter). This leads to the situation that
 even after the thread finished its work making the future ready, the
 shared state still holds on to the thread and the thread structure still
 holds a reference to the shared state.
 This makes the future immortal and thus the resources are never released.

 A workaround is to undefine the flag. This has the side effect that the
 destructor of the future won't block which sometimes is undesirable (and
 which was the reason the flag was introduced). Using deferred launch
 policy doesn't lead to the memory leak since no new thread is launched for
 the execution of the continuation.

 Please respond to this ticket, a memory leak makes the continuations
 unusable.

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/12220#comment:1>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.