<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 4 Mar 2022 at 12:14, Sandeep Bhardwaj via Boost-users <<a href="mailto:boost-users@lists.boost.org">boost-users@lists.boost.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Need to check that. Just to be a little more clear, my requirements for the http server are pretty basic and if it can serve just one request at a time, it would serve my requirement. With this requirement, if io_context object can be stopped and post that if we clear the ssl related stuff and then start io_context again to serve the next request, would it help in clearing the memory being held? Any thoughts?<br></div></blockquote><div><br></div><div>The io_context is a separate, orthogonal concern to the ssl::context.</div><div><br></div><div>The io_context represents your program's io loop. Normally there would be only one per program.<br><br>The ssl::context represents a common set of parameters for negotiating SSL sessions and acts as a container for those sessions. Note that these SSL sessions are not necessarily associated with any particular TCP connection - they merely represent the state of an encrypted tunnel over some transport. You would normally have one ssl::context per domain in your program. For example, a server that accepted inbound connections from the internet but then made outbound connections to a specific set of servers guarded by private keys, might use two ssl::context objects - one for all inbound connections and one for all outbound.</div><div><br></div><div>Destroying the ssl::context and recreating is possible but I don't think it gains you anything. It might be that the context simply keeps hold of allocated memory in anticipation of re-using it. In this case, allowing it to cache memory is harmless. If the memory use grows during the lifetime of the program, then this might be more serious. But I have never experienced this.</div><div><br></div><div>Destroying and recreating the io_context serves no purpose whatsoever. It simply means that cached services will be destroyed and re-created each time you service a request.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 4 Mar 2022 at 13:29, Richard Hodges via Boost-users <<a href="mailto:boost-users@lists.boost.org" target="_blank">boost-users@lists.boost.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Yes this is too early. I would expect these functions ti be called in the destructor of your ssl stream object</div><div dir="auto">Can you confirm that this is actually destroyed?</div><div dir="auto">Maybe put a breakpoint in the destructor of asio::ssl::stream ?</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 4 Mar 2022 at 08:34, Sandeep Bhardwaj via Boost-users <<a href="mailto:boost-users@lists.boost.org" target="_blank">boost-users@lists.boost.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>My bad. I probably spoke too soon. It is resulting in invalid write.</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 4 Mar 2022 at 11:21, Sandeep Bhardwaj <<a href="mailto:sandybharblore@gmail.com" target="_blank">sandybharblore@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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. <br></div><div>Is this fine? any comments?<br></div><div><br></div><div> void<br> on_shutdown(beast::error_code ec)<br> {<br> if(ec)<br> return fail(ec, "shutdown");<br><br><b> std::cout<<"Shutting down"<<std::endl;<br> SSL *ssl = stream_.native_handle();<br> SSL_SESSION *session_object = SSL_get_session(ssl);<br> SSL_SESSION_free(session_object);</b><br> // At this point the connection is closed gracefully<br> }</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 4 Mar 2022 at 01:53, Richard Hodges via Boost-users <<a href="mailto:boost-users@lists.boost.org" target="_blank">boost-users@lists.boost.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 3 Mar 2022 at 18:25, Sandeep Bhardwaj via Boost-users <<a href="mailto:boost-users@lists.boost.org" target="_blank">boost-users@lists.boost.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Hi,</div><div dir="ltr"><br></div><div> 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.</div></div></blockquote><div><br></div><div>It's entirely possible that OpenSSL caches memory, which would be beyond the responsibility of Beast or Asio.</div><div><br></div><div>I don't see anything controversial in your program.<br><br>I see this on stack overflow, but no answers:<br><a href="https://stackoverflow.com/questions/56355690/valgrind-reports-memory-leak-related-with-crypto-zalloc-in-a-c-app-but-no-addi" target="_blank">https://stackoverflow.com/questions/56355690/valgrind-reports-memory-leak-related-with-crypto-zalloc-in-a-c-app-but-no-addi</a><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div><br></div><div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 4 Feb 2022 at 12:28, Sandeep Bhardwaj <<a href="mailto:sandybharblore@gmail.com" target="_blank">sandybharblore@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Thanks a lot. I will give it a try.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 3 Feb 2022 at 23:15, Vinnie Falco <<a href="mailto:vinnie.falco@gmail.com" target="_blank">vinnie.falco@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, Feb 3, 2022 at 9:41 AM Sandeep Bhardwaj via Boost-users<br>
<<a href="mailto:boost-users@lists.boost.org" target="_blank">boost-users@lists.boost.org</a>> wrote:<br>
> http_server_sync_ssl.cpp<br>
<br>
Oh, right. Synchronous APIs have no way to time out. So if the remote<br>
host does not close gracefully (i.e. just slams the connection shut)<br>
then you will be left with a connection object which either has no way<br>
to be destroyed, or has to wait what could be a very long time (up to<br>
2 hours) for the operating system to time out the synchronous read.<br>
<br>
Please try the asynchronous example, http_server_async_ssl.cpp and<br>
determine if the problem persists.<br>
<br>
Thanks<br>
</blockquote></div>
</blockquote></div></div>
_______________________________________________<br>
Boost-users mailing list<br>
<a href="mailto:Boost-users@lists.boost.org" target="_blank">Boost-users@lists.boost.org</a><br>
<a href="https://lists.boost.org/mailman/listinfo.cgi/boost-users" rel="noreferrer" target="_blank">https://lists.boost.org/mailman/listinfo.cgi/boost-users</a><br>
</blockquote></div></div>
_______________________________________________<br>
Boost-users mailing list<br>
<a href="mailto:Boost-users@lists.boost.org" target="_blank">Boost-users@lists.boost.org</a><br>
<a href="https://lists.boost.org/mailman/listinfo.cgi/boost-users" rel="noreferrer" target="_blank">https://lists.boost.org/mailman/listinfo.cgi/boost-users</a><br>
</blockquote></div>
</blockquote></div>
_______________________________________________<br>
Boost-users mailing list<br>
<a href="mailto:Boost-users@lists.boost.org" target="_blank">Boost-users@lists.boost.org</a><br>
<a href="https://lists.boost.org/mailman/listinfo.cgi/boost-users" rel="noreferrer" target="_blank">https://lists.boost.org/mailman/listinfo.cgi/boost-users</a><br>
</blockquote></div></div>-- <br><div dir="ltr"><div dir="ltr"><div><div dir="ltr">Richard Hodges<div><a href="mailto:hodges.r@gmail.com" target="_blank">hodges.r@gmail.com</a></div><div>office: +44 2032 898 513</div><div>home: +376 861 195</div><div>mobile: +376 380 212</div><div><br></div></div></div></div></div>
_______________________________________________<br>
Boost-users mailing list<br>
<a href="mailto:Boost-users@lists.boost.org" target="_blank">Boost-users@lists.boost.org</a><br>
<a href="https://lists.boost.org/mailman/listinfo.cgi/boost-users" rel="noreferrer" target="_blank">https://lists.boost.org/mailman/listinfo.cgi/boost-users</a><br>
</blockquote></div>
_______________________________________________<br>
Boost-users mailing list<br>
<a href="mailto:Boost-users@lists.boost.org" target="_blank">Boost-users@lists.boost.org</a><br>
<a href="https://lists.boost.org/mailman/listinfo.cgi/boost-users" rel="noreferrer" target="_blank">https://lists.boost.org/mailman/listinfo.cgi/boost-users</a><br>
</blockquote></div></div>