You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Igor Sapego (Jira)" <ji...@apache.org> on 2022/10/18 07:42:00 UTC

[jira] [Updated] (IGNITE-17922) C++ Thin: SIGSEGV on connection closed

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

Igor Sapego updated IGNITE-17922:
---------------------------------
    Description: 
Let’s consider some simple program:

{code:cpp}
#include <ignite/thin/ignite_client.h>
#include <iostream>
#include <thread>
#include <chrono>

int main() {
    ignite::thin::IgniteClientConfiguration cfg;
    cfg.SetEndPoints("127.0.0.1");
    cfg.SetConnectionTimeout(2000);

    auto client = ignite::thin::IgniteClient::Start(cfg);

    auto cache = client.GetOrCreateCache<int64_t, int64_t>("person");

    try {
        while (true) {
            int64_t size;
            try {
                size = cache.GetSize(4);
                std::cout << size << "\n";

            } catch (ignite::IgniteError& e) {
                std::cerr << e.what() << "\n";
            }

            std::this_thread::sleep_for(std::chrono::milliseconds{1000});
        }
    } catch (...) {
        std::cerr << "Exception thrown\n";
    }
}
{code}
During server restart this program could crash because of data race.

It seems problem here: {{DataRouter::OnConnectionClosed}}.


{code:cpp}
void DataRouter::OnConnectionClosed(uint64_t id, const IgniteError* err)
            {
                SP_DataChannel channel;
                {
                    common::concurrent::CsLockGuard lock(channelsMutex);

                    channel = FindChannelLocked(id);

                    connectedChannels.erase(id);
                    InvalidateChannelLocked(channel);
                }

                channel.Get()->FailPendingRequests(err);
            }
{code}

Local variable channel initialized as {{nullptr}}, thus calling {{channel.Get()->}} yields signal throw.

It seems {{FindChannelLocked}} call was unsuccessful, because objected was deleted in another thread (in this example most likely in main thread  during {{GetSize}})

I suggest WA to check {{SP_DataChannel}} state before dereferencing it.


  was:
Let’s consider some simple program:

{code:cpp}
#include <ignite/thin/ignite_client.h>
#include <iostream>
#include <thread>
#include <chrono>

int main() {
    ignite::thin::IgniteClientConfiguration cfg;
    cfg.SetEndPoints("127.0.0.1");
    cfg.SetConnectionTimeout(2000);

    auto client = ignite::thin::IgniteClient::Start(cfg);

    auto cache = client.GetOrCreateCache<int64_t, int64_t>("person");

    try {
        while (true) {
            int64_t size;
            try {
                size = cache.GetSize(4);
                std::cout << size << "\n";

            } catch (ignite::IgniteError& e) {
                std::cerr << e.what() << "\n";
            }

            std::this_thread::sleep_for(std::chrono::milliseconds{1000});
        }
    } catch (...) {
        std::cerr << "Exception thrown\n";
    }
}
{code}
During server restart this program could crash because of data race.

It seems problem here: {{DataRouter::OnConnectionClosed}}.


{code:cpp}
void DataRouter::OnConnectionClosed(uint64_t id, const IgniteError* err)
            {
                SP_DataChannel channel;
                {
                    common::concurrent::CsLockGuard lock(channelsMutex);

                    channel = FindChannelLocked(id);

                    connectedChannels.erase(id);
                    InvalidateChannelLocked(channel);
                }

                channel.Get()->FailPendingRequests(err);
            }
{code}

Local variable channel initialized as {{nullptr}}, thus calling {{channel.Get()->}} yields signal throw.

It seems {{FindChannelLocked }}call was unsuccessful, because objected was deleted in another thread (in this example most likely in main thread  during {{GetSize}})

I suggest WA to check {{SP_DataChannel }}state before dereferencing it.



> C++ Thin: SIGSEGV on connection closed
> --------------------------------------
>
>                 Key: IGNITE-17922
>                 URL: https://issues.apache.org/jira/browse/IGNITE-17922
>             Project: Ignite
>          Issue Type: Improvement
>          Components: thin client
>    Affects Versions: 2.14
>            Reporter: Igor Sapego
>            Assignee: Igor Sapego
>            Priority: Major
>             Fix For: 2.15
>
>
> Let’s consider some simple program:
> {code:cpp}
> #include <ignite/thin/ignite_client.h>
> #include <iostream>
> #include <thread>
> #include <chrono>
> int main() {
>     ignite::thin::IgniteClientConfiguration cfg;
>     cfg.SetEndPoints("127.0.0.1");
>     cfg.SetConnectionTimeout(2000);
>     auto client = ignite::thin::IgniteClient::Start(cfg);
>     auto cache = client.GetOrCreateCache<int64_t, int64_t>("person");
>     try {
>         while (true) {
>             int64_t size;
>             try {
>                 size = cache.GetSize(4);
>                 std::cout << size << "\n";
>             } catch (ignite::IgniteError& e) {
>                 std::cerr << e.what() << "\n";
>             }
>             std::this_thread::sleep_for(std::chrono::milliseconds{1000});
>         }
>     } catch (...) {
>         std::cerr << "Exception thrown\n";
>     }
> }
> {code}
> During server restart this program could crash because of data race.
> It seems problem here: {{DataRouter::OnConnectionClosed}}.
> {code:cpp}
> void DataRouter::OnConnectionClosed(uint64_t id, const IgniteError* err)
>             {
>                 SP_DataChannel channel;
>                 {
>                     common::concurrent::CsLockGuard lock(channelsMutex);
>                     channel = FindChannelLocked(id);
>                     connectedChannels.erase(id);
>                     InvalidateChannelLocked(channel);
>                 }
>                 channel.Get()->FailPendingRequests(err);
>             }
> {code}
> Local variable channel initialized as {{nullptr}}, thus calling {{channel.Get()->}} yields signal throw.
> It seems {{FindChannelLocked}} call was unsuccessful, because objected was deleted in another thread (in this example most likely in main thread  during {{GetSize}})
> I suggest WA to check {{SP_DataChannel}} state before dereferencing it.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)