Memory leak on windows about libraries HOT 7 CLOSED

This is not the leak. Later on the callback_impl the passed parameter is taken as unique_ptr and so the object is deleted after leaving the function. What I could imagine, that the thread pool object must be cleaned somehow. But I will check that tomorrow.

from libraries.

I forwarded the question to Sean and he replied: "The idea with the channels is if you have a generator to construct it as a coroutines in the channel- then you have flow control. Blocking on send() means you have a requirement for “at least one additional thread”, with no upper bound in general. send() is just there to prime the pump."
So in other words, you have to control the values, that you send into your channel.

from libraries.

Hi,
many thanks for reporting this. I will look into it as soon as I can and we will provide a fix in the next release,
Regards, Felix

from libraries.

@FelixPetriconi thanks for a quick response!

I have found a root-cause, it's this:
https://github.com/stlab/libraries/blob/develop/stlab/concurrency/default_executor.hpp#L165

    template <typename F>
    void operator()(F&& f) {
        auto work = CreateThreadpoolWork(&callback_impl<F>,
            new F(std::forward<F>(f)), // here we allocate memory that is not cleaned
            &_callBackEnvironment);

        if (work == nullptr) {
            throw std::bad_alloc();
        }
        SubmitThreadpoolWork(work);
    }

Not sure what todo about it, since CreateThreadpoolWork always wants a pointer and we do not know when work is done to clean memory.

from libraries.

As far as I can see, there is no memory leak in the channel library. I wrote small test program and I checked it with the Intel Memory Leak analyzer.
I can see, that the internal queue, a deque, of the channel increases, because it get the values faster, than they could be processed downstream by the attached receiver. So far there is no mechanism to shrink this deque. There is a mechanism in the channel, that allows to limit this queue size. One has to combine a process with a stlab::buffer_size(value). But this helps only half way, because the sender itself has a queue as well and that cannot be limited so far. We will discuss internally, how we can improve this.
I see a similar behavior when I use the STLAB_TASK_SYSTEM_PORTABLE.

from libraries.

@FelixPetriconi thanks for investigation, indeed I saw memory problems with portable version too. But compare to windows version, it is possible to control memory (for my app type) by using thread sleeps, so that queue can actually be dequed.

However, this tactics does not help to windows version and it leaks a lot of memory regardless of deque.

And it depends on an object size that you send into a channel, that's why I am not sure that its cleaned well.

We will discuss internally, how we can improve this.

Thanks, looking forward to it!

from libraries.

@FelixPetriconi hi, any news on it?

from libraries.