Multiplexing seems to periodically crash the SyncClient during Client Reset

[cmelchior]

Reported internally on Slack here: https://mongodb.slack.com/archives/CUSNYAJ4R/p1684334160942949

Seen by JS, Kotlin and Swift.

This is a CI run on Kotlin hitting this: https://ci.realm.io/blue/organizations/jenkins/realm%2Frealm-kotlin/detail/main/120/pipeline

So far, it has not been possible to reproduce it locally.

# A fatal error has been detected by the Java Runtime Environment:
#  SIGSEGV (0xb) at pc=0x000000012aad380b, pid=79762, tid=129599
# Problematic frame:
# C  [librealmc.dylib+0x2a080b]  _ZN5realm4sync10ClientImpl7Session15call_debug_hookERKNS_18SyncClientHookDataE+0x8b

So far the theory is that this is connected to multiplexing which was just recently enabled.

Multiplexing can be disabled again using realm_sync_client_config_set_multiplex_sessions() in the C-API. We need more testing to figure out if this is enough to work around the problem until a proper fix can be found.

[sync-by-unito]

➤ michael-wb commented:

Here is the conversation for the failure seen with the JS SDK: https://mongodb.slack.com/archives/CUSNYAJ4R/p1684334160942949

This was seen when a JSON error was received from the server, resulting in the crash.

[sync-by-unito]

➤ michael-wb commented:

The SessionWrapper has a pointer to the ClientImpl::Session and the Connection holds the unique_ptr for the Session. In addition, the Session has references to its SessionWrapper and Connection.
There is a tiny window when the session is being torn down where the SessionWrapper has been destroyed, but the Session instance is still around since the BIND message has not been sent yet.
For this crash, the Session is in the process of being torn down when a message is received from the connection that causes the Session to call functions on the SessionWrapper instance, which now points to an object that has been destroyed.

Investigating the best way to handle the different lifetimes...