I'm facing the same issue that was reported initially on this thread Looking at the C++ client API and generated code, it seems that channels are intended to be long-lived and shared (std::shared_ptr), while stub are intended to be short lived (std::unique_ptr).
If I keep one long lived channel and create / destroy stubs for every call or so, method registrations keep accumulating in the channel until the channel is destroyed. While this is not strictly speaking leaked memory (unreferenced memory that is never released), this usage pattern results in unbounded growth of memory usage, which has the same effect as a memory leak. If I keep long lived channels and short-lived stubs, is there a way to cleanup the methods registration from the channel when the stubs go away? On Wednesday, January 31, 2018 at 8:12:59 AM UTC-8, Yang Gao wrote: > > Hi, > > We will need some more details to understand what is going on. But I am > not aware of any leaking in stub and channel. > You can either provide some sort of repro or some debug information to > show that memory has been leaked. > Thanks. > > On Tue, Jan 30, 2018 at 10:11 PM, <[email protected] <javascript:>> wrote: > >> I am facing this problem , can you give a help ? thanks >> >> 在 2016年9月28日星期三 UTC+8上午8:17:48，[email protected]写道： >>> >>> I am tracking down a memory leak, and it leads to the NewStub call >>> (async in my case). In our code, for every rpc request from the client, a >>> NewStub is created to send the request. The stub object returned from >>> NewStub is correctly deleted (as a unique_ptr), but something else during >>> the call is not. >>> >>> From the code, Stub::Stub sets the RpcMethod object. RpcMethod's >>> constructor calls channel->RegisterMethod(name), which then calls >>> grpc_channel_register_call who does a gpr_malloc(sizeof(registered_call)). >>> I am not sure when this memory should be freed, but jeprof also reports >>> this gpr_malloc is leaking. >>> >>> I also tried turning on GRPC_TRACE, and saw this >>> grpc_channel_register_call, but never the one that frees the memory. Maybe >>> I am not familiar with the grpc code, but can someone explain how this >>> memory is freed? >>> >>> Thanks for any pointer. >>> >>> -- >> 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] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> Visit this group at https://groups.google.com/group/grpc-io. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/grpc-io/43762b3c-fee7-434b-9ebc-821bccbca1e4%40googlegroups.com >> >> <https://groups.google.com/d/msgid/grpc-io/43762b3c-fee7-434b-9ebc-821bccbca1e4%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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 post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/grpc-io. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/a05cc213-120d-41e5-ac20-7762db910ed3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
