asio-users

[asio-users] Is this memory leak in demuxer::post()?

[Jeffrey C. <jef...@gm...>]

Hi,

I'm using asio::deadline_timer to implement a dedicate timer thread.  It
works ok, except for a memory leak problem  (reported by Valgrind) when
demuxer::post() is called after demuxer::run() returns.  Here's the stack
trace that shows a "handler_wrapper<Handle>" object is created without
corresponding deletion:

.... asio::basic_demuxer<Demuxer_Service>::post(Handler)
(basic_demuxer.hpp:174), which calls
.... asio::demuxer_service<Allocator>::post(Handler)
(demuxer_service.hpp:124), which calls
    211   template <typename Handler>
    212   void post(Handler handler)
    213   {
    214     boost::asio::detail::mutex::scoped_lock lock(mutex_);
    215
    216     // Add the handler to the end of the queue.
    217     handler_base* h =3D new handler_wrapper<Handler>(handler);
    218     if (handler_queue_end_)
    219     {
    220       handler_queue_end_->next_ =3D h;
    221       handler_queue_end_ =3D h;
    222     }
    223     else
    224     {
    225       handler_queue_ =3D handler_queue_end_ =3D h;
    226     }
    227
    228     // An undelivered handler is treated as unfinished work.
    229     ++outstanding_work_;
    230
    231     // Wake up a thread to execute the handler.
    232     if (!interrupt_one_idle_thread())
    233       interrupt_task();
    234   }

It looks like that, if demuxer::run() has finished and there's no thread to
be waken up (in Line#231-234) for serving the posted Handler "*h" (created
in Line#217), then "*h" is left alone without destruction  Is this a bug?

I'm using boost-asio-proposal-0.3.6.

--- Jeffrey

Re: [asio-users] Is this memory leak in demuxer::post()?

[Christopher K. <ch...@ko...>]

Hi Jeffrey,

--- Jeffrey Chang <jef...@gm...> wrote:
> I'm using asio::deadline_timer to implement a dedicate timer
> thread. It works ok, except for a memory leak problem
> (reported by Valgrind) when demuxer::post() is called after
> demuxer::run() returns.

As of 0.3.6, it is the application's responsibility to call
demuxer::run() until there is no work left to do. Since your app
is not calling demuxer::run() after calling demuxer::post(), it
is not fulfilling that responsibility, hence the leak.

For convenience, I'm looking at cleaning up undelivered handlers
in the demuxer's destructor, but that's for a future version.

For now, to implement a clean shutdown you should cancel all
timers and wait for the demuxer::run() call to return normally.
It will return once all handlers have been delivered.

Cheers,
Chris