I have added some code in on_shutdown to get the session object and free it
explicitly. The same stack is not observed in the valgrind report anymore.
Is this fine? any comments?
void
on_shutdown(beast::error_code ec)
{
if(ec)
return fail(ec, "shutdown");
* std::cout<<"Shutting down"<
On Thu, 3 Mar 2022 at 18:25, Sandeep Bhardwaj via Boost-users < boost-users@lists.boost.org> wrote:
Hi,
I tried the async program as suggested and I still see one of the stacks where the "still reachable" memory keeps increasing with duration. I have attached the relevant stack and the program. Sorry I had to resend this email multiple times due to size limitations. Hopefully this will go through.
It's entirely possible that OpenSSL caches memory, which would be beyond the responsibility of Beast or Asio.
I don't see anything controversial in your program.
I see this on stack overflow, but no answers:
https://stackoverflow.com/questions/56355690/valgrind-reports-memory-leak-re...
On Fri, 4 Feb 2022 at 12:28, Sandeep Bhardwaj
wrote: Thanks a lot. I will give it a try.
On Thu, 3 Feb 2022 at 23:15, Vinnie Falco
wrote: On Thu, Feb 3, 2022 at 9:41 AM Sandeep Bhardwaj via Boost-users
wrote: http_server_sync_ssl.cpp
Oh, right. Synchronous APIs have no way to time out. So if the remote host does not close gracefully (i.e. just slams the connection shut) then you will be left with a connection object which either has no way to be destroyed, or has to wait what could be a very long time (up to 2 hours) for the operating system to time out the synchronous read.
Please try the asynchronous example, http_server_async_ssl.cpp and determine if the problem persists.
Thanks
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users