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
