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

Sandeep Bhardwaj via Boost-users <[email protected]>
Newsgroups gmane.comp.lib.boost.user
Message-ID <CAHdo=KsNkLbr++wpFyH_jAoXXG+uZqXbAya2-P+NrhQD5Wx2wA@mail.gmail.com>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.