My bad. I probably spoke too soon. It is resulting in invalid write.



On Fri, 4 Mar 2022 at 11:21, Sandeep Bhardwaj <sandybharblore@gmail.com> 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 <boost-users@lists.boost.org> wrote:


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-related-with-crypto-zalloc-in-a-c-app-but-no-addi


 




On Fri, 4 Feb 2022 at 12:28, Sandeep Bhardwaj <sandybharblore@gmail.com> wrote:
Thanks a lot. I will give it a try.

On Thu, 3 Feb 2022 at 23:15, Vinnie Falco <vinnie.falco@gmail.com> wrote:
On Thu, Feb 3, 2022 at 9:41 AM Sandeep Bhardwaj via Boost-users
<boost-users@lists.boost.org> 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