Boost logo

Boost Users :

From: Sandeep Bhardwaj (sandybharblore_at_[hidden])
Date: 2022-03-04 11:14:06


Need to check that. Just to be a little more clear, my requirements for the
http server are pretty basic and if it can serve just one request at a
time, it would serve my requirement. With this requirement, if io_context
object can be stopped and post that if we clear the ssl related stuff and
then start io_context again to serve the next request, would it help in
clearing the memory being held? Any thoughts?

On Fri, 4 Mar 2022 at 13:29, Richard Hodges via Boost-users <
boost-users_at_[hidden]> wrote:

> 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 <
> boost-users_at_[hidden]> wrote:
>
>> My bad. I probably spoke too soon. It is resulting in invalid write.
>>
>>
>>
>> On Fri, 4 Mar 2022 at 11:21, Sandeep Bhardwaj <sandybharblore_at_[hidden]>
>> 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_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
>>>>
>>> _______________________________________________
>> Boost-users mailing list
>> Boost-users_at_[hidden]
>> https://lists.boost.org/mailman/listinfo.cgi/boost-users
>>
> --
> Richard Hodges
> hodges.r_at_[hidden]
> office: +44 2032 898 513
> home: +376 861 195
> mobile: +376 380 212
>
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> https://lists.boost.org/mailman/listinfo.cgi/boost-users
>



Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net