[fix][c++ client] avoid race condition causing double callback on close

[Matt-Esch]

Motivation

The pulsar-client-node library uses the c api to interact with the pulsar client. The model for the c api is to pass in a void *ctx to async functions with a callback. Typically, these callbacks free the context and rely heavily on the fact that the callback is called once. I was able to reproducibly trigger the close callback to call twice, resulting in a double free error in pulsar-client-node.

Modifications

My running theory is that the cause for this is a race condition in the decrementing of numberOfOpenHandlers shared pointer. It is possible for two threads to decrement the number in parallel, and to both end up with *numberOfOpenHandlers == 0. This fix assumes this can happen and synchronizes on the state, so even if this does happen, only one thread will be able to set the state to Closed and create the subsequent shutdown task.

Verifying this change

• Make sure that the change passes the CI checks.
• Run reproduction steps with pulsar-client-node using the new version

This change is already covered by existing tests, such as all of the tests in ClientTest.cc. Given that this is a race condition it's not possible to reproduce consistently for tests. I will run reproduction steps with pulsar-client-node.

Does this pull request potentially affect one of the following parts:

• Dependencies (does it add or upgrade a dependency): no
• The public API: no
• The schema: no
• The default values of configurations: no
• The wire protocol: no
• The rest endpoints: no
• The admin cli options: no
• Anything that affects deployment: no

Documentation

• doc-required

• no-need-doc

• doc

• doc-added

[merlimat]

The problem is that the decrement and checking of the counter are not done in atomic fashion:

    if (*numberOfOpenHandlers > 0) {
        --(*numberOfOpenHandlers);
    }
    if (*numberOfOpenHandlers == 0) {
        // .....
    }

We should instead convert into:

    if (--(*numberOfOpenHandlers) == 0) {
        // .....
    }

[Matt-Esch]

Are we guaranteed that --(*numberOfOpenHandlers) == 0 is atomic if the underlying data type isn't atomic? The fix I have put in place allows the decrement race but still only one thread can win due to the lock.

[merlimat]

You're right, I was convinced we were using std::atomic<int> but we're not..