Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: Fix gRCP context leaks. #904

Merged
merged 2 commits into from
Jul 16, 2019

Conversation

devjgm
Copy link
Contributor

@devjgm devjgm commented Jul 13, 2019

The calls to gRPC methods were each allocating new ClientContext
object, then leaking them. ClientContext ownership is retained by the
caller, so it's the caller's responsibility to delete them. The normal
way this is done is to declare a local stack-allocated context, and pass
a pointer to that.

I also did a few small C++-y cleanups, such as the following:

  • Removed the public declaration for SDKImpl by making it a private
    internal class. Also, declare this as a struct rather than class
    since it had all public fields.

  • Removed the kPort int. It was never needed as an int, only a string.
    And it was only ever used in one place. The Google style guide says
    that data should be declared in the smallest scope possible, so
    declaring that at file-scope was too broad. In this case, the best
    solution is to just declare the grpc "target" as a string inline
    since it's needed in exactly one place.

  • Using std::move() to efficiently move (not copy) the string value
    function arguments.

  • Fixed formatting in .cc file to match .h file by putting the pointer
    asterisk adjacent to the type (this matches the .h file).

I verified that all the code still compiles by running make, but I
have not run any tests because AFAICT, there are no unit tests.

@markmandel
Copy link
Member

@dsazonoff any issues?

@markmandel markmandel added area/performance Anything to do with Agones being slow, or making it go faster. kind/bug These are bugs. kind/cleanup Refactoring code, fixing up documentation, etc labels Jul 13, 2019
@agones-bot
Copy link
Collaborator

Build Succeeded 👏

Build Id: 603049a6-6a5b-4f59-b04b-ec2338c4a0c7

The following development artifacts have been built, and will exist for the next 30 days:

A preview of the website (the last 30 builds are retained):

To install this version:

  • git fetch https://github.com/GoogleCloudPlatform/agones.git pull/904/head:pr_904 && git checkout pr_904
  • helm install install/helm/agones --namespace agones-system --name agones --set agones.image.tag=0.12.0-473f1bb


stable::agones::dev::sdk::KeyValue request;
request.set_key(key);
request.set_value(value);
request.set_key(std::move(key));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

std::move is redundant here and in next calls of set_key and set_value because it accepts argument via const reference.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since C++11, protos also have setters that take rvalues to support efficient moves. To quote from this doc:

void set_foo(string&& value) (C++11 and beyond): Sets the value of the field, moving from the passed string. After calling this, foo() will return a copy of value.

So I think we want to do one of the following:

A: Keep these moves, or ...
B: Change the function's argument types to be const std::string& and not move.

I recommend (A).

request.set_key(key);
request.set_value(value);
request.set_key(std::move(key));
request.set_value(std::move(value));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove std::move

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See previous reply.


stable::agones::dev::sdk::KeyValue request;
request.set_key(key);
request.set_value(value);
request.set_key(std::move(key));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove std::move

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See previous reply.

request.set_key(key);
request.set_value(value);
request.set_key(std::move(key));
request.set_value(std::move(value));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove std::move

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See previous reply.

Copy link
Contributor

@dsazonoff dsazonoff left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

std::move should be removed when passings strings, because set_key and set_value methods accepts const reference.

@agones-bot
Copy link
Collaborator

Build Failed 😱

Build Id: 046a1317-bee5-405d-928d-7c60fefc1121

To get permission to view the Cloud Build view, join the agones-discuss Google Group.

@devjgm
Copy link
Contributor Author

devjgm commented Jul 14, 2019

I think the build failure is an unrelated flake.

@dsazonoff
Copy link
Contributor

@markmandel could you restart a build, please. Code is Ok.

The calls to gRPC methods were each allocating new `ClientContext`
object, then leaking them. ClientContext ownership is retained by the
caller, so it's the caller's responsibility to delete them. The normal
way this is done is to declare a local stack-allocated context, and pass
a pointer to that.

I also did a few small C++-y cleanups, such as the following:

*  Removed the public declaration for `SDKImpl` by making it a private
   internal class. Also, declare this as a struct rather than class
   since it had all public fields.

*  Removed the kPort int. It was never needed as an int, only a string.
   And it was only ever used in one place. The Google style guide says
   that data should be declared in the smallest scope possible, so
   declaring that at file-scope was too broad. In this case, the best
   solution is to just declare the grpc "target" as a string inline
   since it's needed in exactly one place.

*  Using `std::move()` to efficiently move (not copy) the string value
   function arguments.

*  Fixed formatting in .cc file to match .h file by putting the pointer
   asterisk adjacent to the type (this matches the .h file).

I verified that all the code still compiles by running `make`, but I
have not run any tests because AFAICT, there are no unit tests.
@agones-bot
Copy link
Collaborator

Build Succeeded 👏

Build Id: 1a2cdbc2-9d6f-430c-826f-e67f7b94781f

The following development artifacts have been built, and will exist for the next 30 days:

A preview of the website (the last 30 builds are retained):

To install this version:

  • git fetch https://github.com/GoogleCloudPlatform/agones.git pull/904/head:pr_904 && git checkout pr_904
  • helm install install/helm/agones --namespace agones-system --name agones --set agones.image.tag=0.12.0-8c7a9ec

@agones-bot
Copy link
Collaborator

Build Succeeded 👏

Build Id: 89d12e4e-4c84-46fd-87ac-ead21569a5e5

The following development artifacts have been built, and will exist for the next 30 days:

A preview of the website (the last 30 builds are retained):

To install this version:

  • git fetch https://github.com/GoogleCloudPlatform/agones.git pull/904/head:pr_904 && git checkout pr_904
  • helm install install/helm/agones --namespace agones-system --name agones --set agones.image.tag=0.12.0-6787681

@markmandel markmandel merged commit 787f57f into googleforgames:master Jul 16, 2019
@roberthbailey roberthbailey added this to the 0.12.0 milestone Jul 26, 2019
@devjgm devjgm deleted the fix-context-leak branch January 23, 2020 14:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/performance Anything to do with Agones being slow, or making it go faster. kind/bug These are bugs. kind/cleanup Refactoring code, fixing up documentation, etc
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants