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/ca725039-c9e7-4638-a756-f9c5b89acda5n%40googlegroups.com.
