Socket_getReadySocket signal SIGSEGV, Segmentation fault.

[maikebing]

The reason is not known at this time, and if there are any findings, feedback will continue

Program received signal SIGSEGV, Segmentation fault.
[Switching to LWP 14087]
0xb6d9778c in memcpy () from /lib/libc.so.6
#0  0xb6d9778c in memcpy () from /lib/libc.so.6
#1  0x0046eaa4 in Socket_getReadySocket (more_work=0, timeout=1000, 
    mutex=0x5e6688 <socket_mutex_store>, rc=0xa36fed58)
    at paho.mqtt.c/src/Socket.c:528
#2  0x00466fe0 in MQTTAsync_cycle (sock=0xa36fee10, timeout=1000, 
    rc=0xa36fee14) at paho.mqtt.c/src/MQTTAsyncUtils.c:2995
#3  0x00464a84 in MQTTAsync_receiveThread (n=0xa3f1e5b8)
    at paho.mqtt.c/src/MQTTAsyncUtils.c:2016
#4  0xb6e8d084 in start_thread () from /lib/libpthread.so.0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
A debugging session is active.

[akai-123]

I encountered the same Segmentation fault, which often occurs when the mqtt server connection is not connected (for example, a non-existing ip is deliberately written).
And found that when calling the Socket_getReadySocket function, mod_s.nfds in it will be modified. It seems that there are threads that are not locked by socket_mutex have changed mod_s. Between the realloc and memcpy in Socket_getReadySocket, mod_s.nfds seem may be modified by mod_s.nfds++ in the Socket_addSocket, resulting in a segmentation fault.

[Stannieman]

We encountered at least 2 crashes that might be caused by or related to this.

0  libsystem_platform.dylib       0x16b2 _platform_strlen + 18
1  libsystem_c.dylib              0x458fc __vfprintf + 4639
2  libsystem_c.dylib              0x51fe4 _vsnprintf + 316
3  libsystem_c.dylib              0x520a4 vsnprintf + 95
4  AidEngine                      0x906d1 Log + 209
5  AidEngine                      0x9b0af myrealloc + 207
6  AidEngine                      0x8e8b5 Socket_getReadySocket + 245
7  AidEngine                      0xa1ede MQTTAsync_receiveThread + 446
8  libsystem_pthread.dylib        0x64e1 _pthread_start + 125
9  libsystem_pthread.dylib        0x1f6b thread_start + 15

0  libsystem_platform.dylib       0x68cb _platform_memmove$VARIANT$Rosetta + 475
1  AidEngine                      0x8e8e8 Socket_getReadySocket + 296
2  AidEngine                      0xa1ede MQTTAsync_receiveThread + 446
3  libsystem_pthread.dylib        0x64e1 _pthread_start + 125
4  libsystem_pthread.dylib        0x1f6b thread_start + 15

This is in the iOS Simulator running with Rosetta enabled. I think iOS 15.7.
@maikebing I now see your PR. Do you think the first one in the logger could also be (indirectly) caused by this?

I also see that 1.3.12 is planned for December of 2023? Is this accurate? 😅

[maikebing]

@Stannieman It looks similar to another issue.
#1219

[icraggs]

The major times when the mod_s.nfds and other entries in the data structure are changed are creating and closing/deleting sockets. The closing/deleting should be already protected, but the creating isn't.

I've added a change which aims to protect adding sockets - it's in the develop branch. If anyone has any chance to try this out to see if it helps, that would be very helpful. Thanks.

[icraggs]

@Stannieman there will definitely be a release in December because there are some urgent fixes to deliver. Whether or not it includes a fix to this depends on whether we find and fix it!

[icraggs]

I've put a fix in, so let's see if it works.