Memory leak with 0.16 Equihash mining

[abitmore]

When the mining threads are being blocked at this line:

work.create( block_id, miner, work.input.nonce )

and a new block arrives, witness_plugin::start_mining will be called again, this line will fail silently and leave some memory leaked.

t->async( [=]()

[theoreticalbts]

Calling async() adds a new routine without cancelling the previous routine. The fc multitasking will schedule both routines to run on the thread.

If the old call is scheduled first, then everything is fine, since the old call will return and clean up its frame before the new call is scheduled. However, since the load is purely computational, if the new call is scheduled first [1], then it will never yield. In this case, there is a memory leak since the old call's data is never cleaned up.

But the stop time check shuts down the new call one second before the next block time, meaning the thread will be executing the old code for about 1 second -- more than enough time for the old call to be scheduled, finish executing and clean up.

[1] This case cannot actually occur because, once it is started, the old call will run to completion! I.e. the async() will enqueue the new call, but it cannot be scheduled until thread t gets into the scheduler, which only happens when the task currently running on t quits (or the current task yields, or the current task does not exist, but neither of these alternatives applies in this scenario).

[abitmore]

With equihash, work.create need for example 10 seconds to complete, only after that, in next loop it will hit the stop check as well as the head_block check. But while it's running, async() will be called 3 more times due to 3 new blocks arriving, so there will be 3 tasks waiting for schedule? If no task will be dropped, then quantity of tasks will accumulate. If one of the tasks will be scheduled and others be dropped without cleanup, then memory leak occurs.

[theoreticalbts]

Superseded by #770