sometimes the app has FD leak, when the APP use fileLock

[qclzdh]

Required information

Operating system:
E.g. Ubuntu 18.04 LTS

Compiler version:
E.g. GCC 7.4.0

Observed result or behaviour:
There are some FD leakage, it could easily reach to the max opened FDs of a process in Linux platform.

Expected result or behaviour:
no FD leakage.

Conditions where it occurred / Performed steps:

APP_A

int main()
{
    //sending();

    iox::runtime::PoshRuntime::initRuntime(APP_NAME);
    auto maybeFileLock = iox::posix::FileLock::create(TEST_NAME);


    while(!iox::posix::hasTerminationRequested()) {
        std::this_thread::sleep_for(std::chrono::seconds(1));
    }

    return (EXIT_SUCCESS);
}

APP_B

int main()
{
    iox::runtime::PoshRuntime::initRuntime(APP_NAME);

    constexpr char TEST_NAME[] = "TestProcessName0630";

    for (int i = 0; i < 1024; i++)
    {
        auto maybeFileLock = iox::posix::FileLock::create(TEST_NAME);

        if (!maybeFileLock.has_error()) {
            // process has exit
            std::cout << "publisher has exit" << std::endl;
        } else {
            if (maybeFileLock.get_error() == iox::posix::FileLockError::LOCKED_BY_OTHER_PROCESS) {
                std::cout << "file is locked by another process" << std::endl;
            } else {
                // normally, this shouldn't happend
                std::cout << "Error occured while acquiring file lock named " << std::endl;
            }
        }
        std::this_thread::sleep_for(std::chrono::milliseconds(50));
    }

{
        auto maybeFileLock = iox::posix::FileLock::create(TEST_NAME);

        if (!maybeFileLock.has_error()) {
            // process has exit
            std::cout << "publisher has exit" << std::endl;
        } else {
            if (maybeFileLock.get_error() == iox::posix::FileLockError::LOCKED_BY_OTHER_PROCESS) {
                std::cout << "file is locked by another process" << std::endl;
            } else {
                // normally, this shouldn't happend
                std::cout << "Error occured while acquiring file lock named " << std::endl;
            }
        }
        std::this_thread::sleep_for(std::chrono::milliseconds(50));
}


    return (EXIT_SUCCESS);
}

and start APP_A first, then start APP_B.
You will see this issue.

[qclzdh]

it seems this issue only can be seen in 2.0.x, master branch has fixed this.

[elfenpiff]

@qclzdh how is the TEST_NAME defined for APP_A, does it have the same value as APP_B?

[qclzdh]

@elfenpiff Sorry for incomplete code, TEST_NAME could be any string, as long as they are same in APP_A and APP_B. I do the test with following definition

constexpr char TEST_NAME[] = "TestProcess0630";

[qclzdh]

@qclzdh how is the TEST_NAME defined for APP_A, does it have the same value as APP_B?

@elfenpiff
Sorry, There is a TEST_NAME defined to "TestProcessName0630", so please make sure they are defined to same one APP_A and APP_B.
Or, maybe you can modify in the test_posix_file_lock.cpp, it could easily reproduce the issue.

// TEST_F(FileLock_test, CreatingSameFileLockAgainFails)
// {
//     ::testing::Test::RecordProperty("TEST_ID", "ed3af1c8-4a84-4d4f-a267-c4a80481dc42");
//     auto sut2 = iox::posix::FileLock::create(TEST_NAME);
//     ASSERT_TRUE(sut2.has_error());
//     EXPECT_THAT(sut2.get_error(), Eq(FileLockError::LOCKED_BY_OTHER_PROCESS));
// }

TEST_F(FileLock_test, DoesNotReachToTheLinuxProcessMaxFile)
{
    ::testing::Test::RecordProperty("TEST_ID", "ed3af1c8-4a84-4d4f-a267-c4a80481dc42");
    for (int i = 0; i < 65536; i++) {
        auto sut2 = iox::posix::FileLock::create(TEST_NAME);
        ASSERT_TRUE(sut2.has_error());
        EXPECT_THAT(sut2.get_error(), Eq(FileLockError::LOCKED_BY_OTHER_PROCESS));
    }
}

[elfenpiff]

@qclzdh Thanks for the test it was very helpful to reproduce the bug.

Now the question is, is it important for you that we release a bug fix 2.0 release or can you work with master? If you could work with master I would create only a PR which fixes the issue and whenever we release a 2.0.3 this fix would be added.

[qclzdh]

@elfenpiff Thanks, master is fine~

[elfenpiff]

Fixed on master with the new builder pattern and on release 2.0.3