I eventually by-pass the problem by reusing the same stub. On Tuesday, September 12, 2017 at 7:21:30 PM UTC+8, Sandeep ananthula wrote: > > hi, > am also facing the same issue, can you please help me if the issue is > resolved for you. > > Thanks in Advance > > > On Wednesday, September 28, 2016 at 5:47:48 AM UTC+5:30, [email protected] > wrote: >> >> 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]. 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/86b86ce0-1c25-4d88-87c0-109121021ac1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
