You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@mesos.apache.org by "Alexander Rojas (JIRA)" <ji...@apache.org> on 2016/10/27 13:40:58 UTC

[jira] [Updated] (MESOS-6484) Memory leak in `Future::after()`

     [ https://issues.apache.org/jira/browse/MESOS-6484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexander Rojas updated MESOS-6484:
-----------------------------------
    Description: 
The problem arises when one tries to associate an {{after()}} call to copied futures. The following test case is enough to reproduce the issue:

{code}
TEST(FutureTest, After3)
{
  auto policy = std::make_shared<int>(0);

  {
    auto generator = []() {
      return Future<Nothing>();
    };

    Future<Nothing> future = generator()
      .after(Milliseconds(1),
        [policy](const Future<Nothing>&) {
           return Nothing();
        });

    AWAIT_READY(future);
  }

  EXPECT_EQ(1, policy.use_count());
}
{code}

In the test, one would expect that there is only one active reference to {{policy}}, therefore the expectation {{EXPECT_EQ(1, policy.use_count())}}. However, if after is triggered more than once, each extra call adds one undeleted reference to {{policy}}.

  was:
The problem arises when one tries to associate an {{after()}} call to copied futures. The following test case is enough to reproduce the issue:

{code}
class Policy
{
public:
  virtual Try<Duration> timeout() = 0;
  virtual Duration totalTimeout() = 0;

  virtual ~Policy() {}
};

class MockPolicy : public Policy
{
public:
  virtual ~MockPolicy() {}

  MOCK_METHOD0(timeout, Try<Duration>());
  MOCK_METHOD0(totalTimeout, Duration());
};

template <typename ResultType>
process::Future<ResultType> retry(
    const std::function<Future<ResultType>()>& action,
    const std::shared_ptr<Policy>& policy)
{
  CHECK(policy != nullptr);

  Try<Duration> timeout = policy->timeout();
  if (timeout.isError()) {
    return Future<ResultType>::failed(timeout.error());
  }

  return action()
    .after(timeout.get(), [action, policy](const Future<ResultType>&) {
      return retry<ResultType>(action, policy);
    });
}

TEST(FutureTest, Retry)
{
  auto policy = std::make_shared<MockPolicy>();

  EXPECT_CALL(*policy, timeout())
      .WillRepeatedly(Return(Milliseconds(1)));

  unsigned callCount = 0;
  auto future = retry<Nothing>([&callCount]() -> Future<Nothing> {
      ++callCount;
      if (callCount < 4) {
        return Future<Nothing>();
      }
      return Nothing();
    },
    policy);

  AWAIT_READY(future);
  EXPECT_EQ(1, policy.use_count());
{code}

In the test, one would expect that there is only one active reference to {{policy}}, therefore the expectation {{EXPECT_EQ(1, policy.use_count())}}. However, if after is triggered more than once, each extra call adds one undeleted reference to {{policy}}.


> Memory leak in `Future<T>::after()`
> -----------------------------------
>
>                 Key: MESOS-6484
>                 URL: https://issues.apache.org/jira/browse/MESOS-6484
>             Project: Mesos
>          Issue Type: Bug
>          Components: libprocess
>    Affects Versions: 1.1.0
>            Reporter: Alexander Rojas
>              Labels: libprocess, mesosphere
>
> The problem arises when one tries to associate an {{after()}} call to copied futures. The following test case is enough to reproduce the issue:
> {code}
> TEST(FutureTest, After3)
> {
>   auto policy = std::make_shared<int>(0);
>   {
>     auto generator = []() {
>       return Future<Nothing>();
>     };
>     Future<Nothing> future = generator()
>       .after(Milliseconds(1),
>         [policy](const Future<Nothing>&) {
>            return Nothing();
>         });
>     AWAIT_READY(future);
>   }
>   EXPECT_EQ(1, policy.use_count());
> }
> {code}
> In the test, one would expect that there is only one active reference to {{policy}}, therefore the expectation {{EXPECT_EQ(1, policy.use_count())}}. However, if after is triggered more than once, each extra call adds one undeleted reference to {{policy}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)