is NewStub (grpc_channel_register_call) leaking memory? (C++)

[douy...@gmail.com]

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.

[Yang Gao]

Hi, The stub can be shared by different calls, but the memory is freed in https://github.com/grpc/grpc/blob/master/src/core/lib/surface/channel.c#L311 

You can try to define GRPC_STREAM_REFCOUNT_DEBUG to have more logs.

--
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 grpc-io+unsubscribe@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
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/4e9482c2-48f3-462e-bce0-8d61e4152b88%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[douy...@gmail.com]

Thanks for the reply. I will try GRPC_STREAM_REFCOUNT_DEBUG.

Just a quick question, when is destroy_channel(...) called? We are using the same channel over and over. Does that mean destroy_channel is not called?

On Thursday, September 29, 2016 at 3:22:44 PM UTC-7, Yang Gao wrote:

Hi, The stub can be shared by different calls, but the memory is freed in https://github.com/grpc/grpc/blob/master/src/core/lib/surface/channel.c#L311 

You can try to define GRPC_STREAM_REFCOUNT_DEBUG to have more logs.

On Tue, Sep 27, 2016 at 5:17 PM, <douy...@gmail.com> 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 grpc-io+u...@googlegroups.com.

[sandeep....@gmail.com]

Hi,

did you got the answer for the below??

Just a quick question, when is destroy_channel(...) called? We are using the same channel over and over. Does that mean destroy_channel is not called?

[Sandeep ananthula]

hi,

am also facing the same issue, can you please help me if the issue is resolved for you.

Thanks in Advance 

[oca...@gmail.com]

I eventually by-pass the problem by reusing the same stub.

[liu...@gmail.com]

I am facing this problem , can you give a help ? thanks

在 2016年9月28日星期三 UTC+8上午8:17:48，douy...@gmail.com写道：

[Yang Gao]

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.

--
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 grpc-io+unsubscribe@googlegroups.com.

To post to this group, send email to grp...@googlegroups.com.
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.