Socket_getReadySocket crash at memcpy because src is null

[HammerCheng]

When the network is abnormal, the connection on the receiving thread is closed.

（1）the stack is as follows：
00 0fd7fb98 69e3070a 00000000 0e887820 00000018 msvcr120!memcpy+0x2a [f:\dd\vctools\crt\crtw32\string\i386\memcpy.asm @ 188]
01 0fd7fbbc 69e2513b 00000000 000003e8 00000324 paho_mqtt3as!Socket_getReadySocket+0x22a
02 0fd7fc78 69e2711f 0fd7fcc0 000003e8 0fd7fcb8 paho_mqtt3as!MQTTAsync_closeSession+0x75b
03 0fd7fd98 769a7ba9 0e30c310 769a7b90 0fd7fe00 paho_mqtt3as!MQTTAsync_receiveThread+0xef
04 0fd7fda8 77c3c11b 0e30c310 6ca074cc 00000000 kernel32!BaseThreadInitThunk+0x19
WARNING: Stack unwind information not available. Following frames may be wrong.
05 0fd7fe00 77c3c09f ffffffff 77c69fbe 00000000 ntdll+0x6c11b
06 0fd7fe10 00000000 69e27030 0e30c310 00000000 ntdll+0x6c09f
（2）the log as follows:
[trace_callback] mqtt trace level:5, message: 19700101 080000.000 Failed to remove heap item at file paho.mqtt.c\src\MQTTProtocolClient.c line 307
[trace_callback] mqtt trace level:5, message: 19700101 080000.000 Failed to remove socket 16468
[trace_callback] mqtt trace level:5, message: 19700101 080000.000 Failed to reallocate heap item at file paho.mqtt.c\src\Socket.c line 541
（3）code:
mod_s.saved.fds_write = realloc(mod_s.saved.fds_write, mod_s.nfds * sizeof(struct pollfd));
if (mod_s.fds_write == NULL)
mod_s.saved.fds_write = NULL;
else
memcpy(mod_s.saved.fds_write, mod_s.fds_write, mod_s.nfds * sizeof(struct pollfd));

Memory allocation failed and subsequent execution of memcpy function crashed

[icraggs]

You don't say what version of the library you are using or the OS or any of the other information requested in the issue template. Without that I cannot help much.

If you aren't using the latest version, you should try that. If the issue exists on the latest version, 1.3.13, then a client library trace as described in the readme would probably be the most help.

[HammerCheng]

[2024-09-02 10:17:34.578] [13052] [INFO ] - [trace_callback] mqtt trace level:3, message: =========================================================
[2024-09-02 10:17:34.578] [13052] [INFO ] - [trace_callback] mqtt trace level:3, message: Trace Output
[2024-09-02 10:17:34.579] [13052] [INFO ] - [trace_callback] mqtt trace level:3, message: Product name: Eclipse Paho Asynchronous MQTT C Client Library
[2024-09-02 10:17:34.579] [13052] [INFO ] - [trace_callback] mqtt trace level:3, message: Version: 1.3.13
[2024-09-02 10:17:34.579] [13052] [INFO ] - [trace_callback] mqtt trace level:3, message: Build level: 2024-06-25T08:33:11Z
[2024-09-02 10:17:34.579] [13052] [INFO ] - [trace_callback] mqtt trace level:3, message: OpenSSL version: OpenSSL 1.1.1j 16 Feb 2021
[2024-09-02 10:17:34.579] [13052] [INFO ] - [trace_callback] mqtt trace level:3, message: OpenSSL flags: compiler: cl /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo /O2 -DLIBZ="zlibwapi.dll" -DL_ENDIAN -DOPENSSL_PIC
[2024-09-02 10:17:34.579] [13052] [INFO ] - [trace_callback] mqtt trace level:3, message: OpenSSL build timestamp: built on: Wed Apr 14 02:09:33 2021 UTC
[2024-09-02 10:17:34.579] [13052] [INFO ] - [trace_callback] mqtt trace level:3, message: OpenSSL platform: platform: VC-WIN32
[2024-09-02 10:17:34.579] [13052] [INFO ] - [trace_callback] mqtt trace level:3, message: OpenSSL directory: OPENSSLDIR: "C:\Program Files (x86)\Common Files

[HammerCheng]

os: windows 10 64
platform: visual studio 2013, x86

[icraggs]

I see you already have some of the trace [trace_callback] - more of that leading up to and after the event would give me an idea of the scenario.

There are also some memory related changes in the develop branch, if you wanted to try that out.

[HammerCheng]

I see you already have some of the trace [trace_callback] - more of that leading up to and after the event would give me an idea of the scenario.

There are also some memory related changes in the develop branch, if you wanted to try that out.

I have created two MQTT5 connections. The first connection is used for subscription, and the second connection is used for publishing. When encountering network problems, both connections will be disconnected at the same time. The second connection will capture the publishing failure in the onFailed 5 function, and this crash will occur.

[HammerCheng]

### Another crash stack:

paho_mqtt3as!MQTTAsync_lock_mutex+0x61d:
6c58647d ff7758 push dword ptr [edi+58h] ds:002b:00320089=????????
*** Stack trace for last set context - .thread/.cxr resets it

ChildEBP RetAddr Args to Child

00 0d91fed0 6c5884b5 6c5883b0 6c5883b0 00000000 paho_mqtt3as!MQTTAsync_lock_mutex+0x61d
01 0d91fee0 76a87ba9 00000000 76a87b90 0d91ff48 paho_mqtt3as!MQTTAsync_sendThread+0x105
02 0d91fef0 77a3c11b 00000000 2ea799d1 00000000 kernel32!BaseThreadInitThunk+0x19
WARNING: Stack unwind information not available. Following frames may be wrong.
03 0d91ff48 77a3c09f ffffffff 77a69fb0 00000000 ntdll+0x6c11b
04 0d91ff58 00000000 6c5883b0 00000000 00000000 ntdll+0x6c09f