My bad. I probably spoke too soon. It is resulting in invalid write.
On Fri, 4 Mar 2022 at 11:21, Sandeep Bhardwaj <sandybharbl...@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 <sandybharbl...@gmail.com>
>>> wrote:
>>>
>>>> Thanks a lot. I will give it a try.
>>>>
>>>> On Thu, 3 Feb 2022 at 23:15, Vinnie Falco <vinnie.fa...@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
>>
>
_______________________________________________
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users
