looking for a memory leak in an asio based application

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

looking for a memory leak in an asio based application

Boost - Users mailing list
I know that the answer to this question is always 'no'. But is it possible, just possible that one can leak memory out of boost::asio?

Let me explain. I work on an open source client/server data streaming library for multi-modal data streaming called labstreaminglayer (https://github.com/sccn/labstreaminglayer). At the core of the data transmission architecture is boost::asio. Now, to avoid calling collisions, the original author of the library shipped the source code with a name-mangled version of boost. Over the years this has yet to be updated so we are still relying on boost 1.57.

The memory leak starts on the server side after a client is connected to it. This went undetected for years because it is very very slow and it depends on the sampling rate of the data stream. LSL (labstreaminglayer) is widely used in the neurophysiological research community (for whom the tool was intended), but normally in that field you are not sending samples faster than 500 Hz or so. But some devices are now available that offer relatively high sampling rates (e.g. Brain Products' actiCHamp can go as fast as 100kHz). The amount of memory that leaks seems to depend on how often data is sent, not how much data is send at a time. So, when the data is flowing quickly, the leak is severe.

I am 99.99% sure that the allocation of memory for all the data I am sending is getting deallocated correctly. I don't see any leaking memory according to Visual Studio's diagnostic tools, nor can Deleaker spot anything. However, when I look at a server process in task manager, I can see the memory rising. I tried the asio::io_<a class="moz-txt-link-freetext" href="service::work">service::work trick (https://stackoverflow.com/questions/32258890/c-boost-asio-async-send-to-memory-leak) on my io_services, but this didn't have any effect.

I have not gone through the whole pipeline yet, but I've been at this for two harrowing days already. So I just thought I would ask the list if anyone has seen anything like this before or if there has been any slow-leak fixes in boost (particularly asio) since 1.57 (I didn't see anything in the logs, but maybe I missed something). Due to the state of the project at this moment, it is non-trivial to update the name-mangled boost to another version, but it is far less trivial than the needle-in-a-haystack game I am playing right now. So, if someone can say with authority a boost update will fix everything I'll just do that and be happy.

It's a long-shot, I know.

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: looking for a memory leak in an asio based application

Boost - Users mailing list
2017-10-05 16:35 GMT+03:00 David Medine via Boost-users
<[hidden email]>:

> I know that the answer to this question is always 'no'. But is it possible,
> just possible that one can leak memory out of boost::asio?
>
> Let me explain. I work on an open source client/server data streaming
> library for multi-modal data streaming called labstreaminglayer
> (https://github.com/sccn/labstreaminglayer). At the core of the data
> transmission architecture is boost::asio. Now, to avoid calling collisions,
> the original author of the library shipped the source code with a
> name-mangled version of boost. Over the years this has yet to be updated so
> we are still relying on boost 1.57.
>

According to the release notices, there is no memory leak was fixed since 1.57

>
> It's a long-shot, I know.
>

Thy this tool: https://github.com/google/sanitizers/wiki/AddressSanitizer
It really saves a lot of time.

> _______________________________________________
> Boost-users mailing list
> [hidden email]
> https://lists.boost.org/mailman/listinfo.cgi/boost-users



--
Best Regards,
Sergei Nikulov
_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users