Boost C++ Libraries: Ticket #9151: memory leak in boost coroutines

attachment set

extproxy@… — Mon, 23 Sep 2013 05:20:35 GMT

attachment → coro.cc

coro.cc

component changed; owner set

anonymous — Mon, 23 Sep 2013 05:23:56 GMT

owner set to olli
component None → coroutine

status changed; resolution set

olli — Mon, 23 Sep 2013 07:49:20 GMT

status new → closed
resolution → invalid

boost.coroutine creates an instance of a coroutine passed as argument to the coro-fn at the new stack stack. This coroutine instance will be destructed only if the stack is unwound. Unwinding is triggered only at destruction. Probably your profiling tool is not aware of this fact. You could take a look at example unwind.cpp which demonstrates that objects allocated on the coroutine stack will be deallocated (you could also add a destructor for push_coroutine which prints soem output if called - and you will see that this destructor will be called).

attachment set

extproxy@… — Mon, 23 Sep 2013 15:27:45 GMT

attachment → coro_mod.cc

extproxy@… — Mon, 23 Sep 2013 15:30:17 GMT

I've modified my program to use custom new/delete operators that print out every allocation and deallocation. The modified program is attached as coro_mod.cc.

It prints the following:

Allocated: 0x9e8010 Allocated: 0x9e8050 Allocated: 0x9e8070 Allocated: 0x9e80b0 Starting main Allocated: 0x9e80d0 Allocated: 0x9e80f0 Allocated: 0x9e81a0 In Hello 6 In Run1 In Hello end 4 In Hello end 5 In Run2 Freeing: 0x9e80f0 Freeing: 0x9e80d0 Finished main Freeing: 0x9e8070 Freeing: 0x9e80b0 Freeing: 0x9e8010 Freeing: 0x9e8050

Notice how there is one more allocation than free.

I compiled it as: g++ -std=c++0x coro_mod.cc -o coro_mod -lboost_context

status changed; resolution deleted

extproxy@… — Mon, 23 Sep 2013 15:31:36 GMT

status closed → reopened
resolution invalid

status changed; resolution set

olli — Mon, 23 Sep 2013 17:00:32 GMT

status reopened → closed
resolution → wontfix

I see that you are using the old/deprecated interface (signature as template arg) of boost.coroutine.

I tried your code with the version in trunk (will be 1.55) and the count of allocations and de-allocations were equal. This means that the old code might contain a memory leak but because this code will be removed from boost.coroutine I won't fix it.