In the example, the shutdown logic should include the following to avoid
memory leak on exit:
// Drain the cq_ that was created
void* tag = nullptr;
bool ignored_ok(false);
while (cq_->Next(&tag, &ignored_ok)) {
CallData* cd = static_cast<CallData*>(tag);
delete cd;
}
On Fri, Oct 30, 2020 at 6:51 PM Christopher Pisz <[email protected]>
wrote:
> I can imagine a hundred scenarios where 'delete this;'
> <https://github.com/grpc/grpc/blob/v1.33.1/examples/cpp/helloworld/greeter_async_server.cc#L115>
> at
> the end of the CallData state machine is never reached.
>
> How about, if we simply start the server and shut it down without any RPC
> calls? proceed would never be called three times, and therefore the delete
> is never reached.
>
> In fact, it seems to me there is always at least one outstanding instance
> that will never have proceed called again on server shutdown.
>
> Additionally, if any exception were to occur during processing, it would
> be lost forever.
>
> Trying to sort this out while not understanding grpc and trying to make
> sense of it, itself, makes this example absolutely horrid. Is there not any
> better examples out there? Can someone with understanding contribute a few?
> How to get gRPC Async and Async Streaming are a complete mystery to me.
>
> On Friday, October 30, 2020 at 5:18:59 PM UTC-4 [email protected] wrote:
>
>> I don't believe it does leak due to the 'delete this;'
>> <https://github.com/grpc/grpc/blob/v1.33.1/examples/cpp/helloworld/greeter_async_server.cc#L115>
>> at the end of the CallData state machine. Though, I agree this is not the
>> best example. It's a bit tenuous to rely on classes to delete themselves.
>> It would be easy to lose track and leak a CallData in error scenarios or
>> with a more complex state machine.
>>
>> Aaron
>>
>> On Friday, October 30, 2020 at 8:44:06 AM UTC-7 [email protected]
>> wrote:
>>
>>> The example at
>>>
>>> https://github.com/grpc/grpc/blob/v1.33.1/examples/cpp/helloworld/greeter_async_server.cc
>>>
>>> has blatantly obvious memory leaks. If CallData allocates itself when
>>> proceed is called, there is no way for it to clean up the new instance when
>>> the server is shutting down. Also, the CallData that is allocated before
>>> the loop even begins can't be cleaned up, since no pointer to it is stored.
>>> I guess the example just doesn't care, as it assumes the process is just
>>> going to abort. However, trying to make sense of CallData, its states, and
>>> how we would do it in the real world isn't obvious with the example in this
>>> state.
>>>
>>> Is there one that doesn't blatantly leak?
>>>
>> --
> You received this message because you are subscribed to the Google Groups "
> grpc.io" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/2c40acd8-8b17-4cdf-8eac-958be7f31d95n%40googlegroups.com
> <https://groups.google.com/d/msgid/grpc-io/2c40acd8-8b17-4cdf-8eac-958be7f31d95n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/grpc-io/CAA-WHun14ckTEtemObmQbiMQYcsFB28kSSgK3tjgHD7%2BHJuAQQ%40mail.gmail.com.
