Re: Boost SSL handshake(http_server_sync_ssl) : still reachable memory keeps increasing

From: Sandeep Bhardwaj (sandybharblore_at_[hidden])
Date: 2022-03-04 05:51:25

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_at_[hidden]> wrote:

>
>
> On Thu, 3 Mar 2022 at 18:25, Sandeep Bhardwaj via Boost-users <
> boost-users_at_[hidden]> 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_at_[hidden]>
>> wrote:
>>
>>> Thanks a lot. I will give it a try.
>>>
>>> On Thu, 3 Feb 2022 at 23:15, Vinnie Falco <vinnie.falco_at_[hidden]>
>>> wrote:
>>>
>>>> On Thu, Feb 3, 2022 at 9:41 AM Sandeep Bhardwaj via Boost-users
>>>> <boost-users_at_[hidden]> 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_at_[hidden]
>> https://lists.boost.org/mailman/listinfo.cgi/boost-users
>>
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> https://lists.boost.org/mailman/listinfo.cgi/boost-users
>