Failed mutex assertion with TCP_sendWithConnection() in 1.4

[sgoll]

Description

Background Information / Reproduction Steps

When issuing concurrent calls to both UA_Client_run_iterate() and __UA_Client_AsyncService(), there is a race condition where the following assertion at the beginning of TCP_sendWithConnection() may fail:

open62541/arch/eventloop_posix_tcp.c

Lines 627 to 629 in 8434782

	/* Don't have a lock and don't take a lock. As the connectionId is the fd,
	* no need to to a lookup and access internal data strucures. */
	UA_LOCK_ASSERT(&((UA_EventLoopPOSIX*)cm->eventSource.eventLoop)->elMutex, 0);

This manifests itself in the following error at runtime. Both functions are marked UA_THREADSAFE:

Assertion failed: (lock->mutexCounter == num), function UA_LOCK_ASSERT, file config.h, line 426.

My guess is that this happens when __UA_Client_AsyncService() tries to send out the request while another thread holds the mutex lock while iterating the event loop from within UA_Client_run_iterate(). Looking at the log output preceding the failed assertion, it seems that at the same time as sending the request, the response to another request arrives at the client:

Iterate the EventLoop
Process delayed callbacks
TCP 5        | SC 262911     | Sending request with RequestId 17 of type BrowseRequest
Processing event 1 on fd 5
TCP 5        | Activity on the socket
TCP 5        | SC 262911     | Send from a symmetric message buffer of length 131072 a message of header+payload length of 9153
TCP 5        | Allocate receive buffer
TCP 5        | SC 262911     | Send from a symmetric message buffer of length 131072 a message of length 9153
Assertion failed: (lock->mutexCounter == num), function UA_LOCK_ASSERT, file config.h, line 426.

Used CMake options:

cmake ..

Checklist

Please provide the following information:

• open62541 Version (release number or git tag): v1.4.0
• Other OPC UA SDKs used (client or server):
• Operating system: macOS
• Logs (with UA_LOGLEVEL set as low as necessary) attached
• Wireshark network dump attached
• Self-contained code example attached
• Critical issue

[sgoll]

@jpfr I'd like to contribute a PR but I'm unsure whether it's sufficient to just remove the assertion (because it describes an invalid assumption) or to actually take the lock instead.