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?
On Fri, 4 Mar 2022 at 13:29, Richard Hodges via Boost-users < [email protected]> wrote: > Yes this is too early. I would expect these functions ti be called in the > destructor of your ssl stream object > Can you confirm that this is actually destroyed? > Maybe put a breakpoint in the destructor of asio::ssl::stream ? > > On Fri, 4 Mar 2022 at 08:34, Sandeep Bhardwaj via Boost-users < > [email protected]> wrote: > >> My bad. I probably spoke too soon. It is resulting in invalid write. >> >> >> >> On Fri, 4 Mar 2022 at 11:21, Sandeep Bhardwaj <[email protected]> >> wrote: >> >>> 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"<<std::endl; SSL *ssl = >>> stream_.native_handle(); SSL_SESSION *session_object = >>> SSL_get_session(ssl); SSL_SESSION_free(session_object);* >>> // At this point the connection is closed gracefully >>> } >>> >>> On Fri, 4 Mar 2022 at 01:53, Richard Hodges via Boost-users < >>> [email protected]> wrote: >>> >>>> >>>> >>>> On Thu, 3 Mar 2022 at 18:25, Sandeep Bhardwaj via Boost-users < >>>> [email protected]> 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-related-with-crypto-zalloc-in-a-c-app-but-no-addi >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Fri, 4 Feb 2022 at 12:28, Sandeep Bhardwaj < >>>>> [email protected]> wrote: >>>>> >>>>>> Thanks a lot. I will give it a try. >>>>>> >>>>>> On Thu, 3 Feb 2022 at 23:15, Vinnie Falco <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> On Thu, Feb 3, 2022 at 9:41 AM Sandeep Bhardwaj via Boost-users >>>>>>> <[email protected]> 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 >>>>> [email protected] >>>>> https://lists.boost.org/mailman/listinfo.cgi/boost-users >>>>> >>>> _______________________________________________ >>>> Boost-users mailing list >>>> [email protected] >>>> https://lists.boost.org/mailman/listinfo.cgi/boost-users >>>> >>> _______________________________________________ >> Boost-users mailing list >> [email protected] >> https://lists.boost.org/mailman/listinfo.cgi/boost-users >> > -- > Richard Hodges > [email protected] > office: +44 2032 898 513 > home: +376 861 195 > mobile: +376 380 212 > > _______________________________________________ > Boost-users mailing list > [email protected] > https://lists.boost.org/mailman/listinfo.cgi/boost-users >
_______________________________________________ Boost-users mailing list [email protected] https://lists.boost.org/mailman/listinfo.cgi/boost-users
