Open x152152 opened 4 months ago
I would try the latest release, 1.3.8 is over 3 years old now.
It seems you have three different connects running simultaneously on separate threads?
It looks more like a premature free rather than memory leak to me.
Is this reproducible? Can you take a client library trace if so (as described in the readme).
I would try the latest release, 1.3.8 is over 3 years old now.
Thanks, I have reproduced this in both 1.3.8 and 1.3.13 versions
It seems you have three different connects running simultaneously on separate threads?
I think it is two connecting threads running at the same time, From the stack I provided, it should be T94 and T87. Thread 97 is from my application's active monitoring. When I find that is_connected() is false, I will connect(). When the program is initialized, thread 87 performs connect and sub,and then rans to MQTTAsync_cycle.In some weak network conditions, SSL and TCP handshake connections will be performed, during this connection process, the SSL resources released during the connection process of thread 97 may be used.My analysis may be wrong, please correct me.
if (m->c->connect_state == TCP_IN_PROGRESS || m->c->connect_state == SSL_IN_PROGRESS || m->c->connect_state == WEBSOCKET_IN_PROGRESS)
*rc = MQTTAsync_connecting(m);
It looks more like a premature free rather than memory leak to me.
Yes, I think so too, I didn't express it clearly enough.
Is this reproducible? Can you take a client library trace if so (as described in the readme).
I ran my program in a weak network environment simulated by my script , I found that it can be reproduced(it may appear after running for 1-2 days).I didn't set the trace environment variable before, I will try to turn on later. Do you need more information? Or is the stack information scanned by the asan tool enough? Thanks. @icraggs
Any reason why you're not using auto reconnect?
If you really want to do it yourself, then it's better to use the connectionLost callback to determine when to reconnect, that's what it's intended for.
I see you're using a C++ client - the Paho one?
Here you've got one thread connecting and two re-connecting. If you are connecting in more than one thread at a time, you should be using different client objects. In fact it looks like you've got two reconnects going before the first connect has completed (going by your method names).
It looks like there are three threads interfering with each other when I think they should be locked out. Not sure how that can happen.
If you can get the full stack trace on version 1.3.13, or a client library trace or perhaps your application program or snippets those could help.
Describe the bug
I found that my program crashed and the stack information was roughly as follows:
==3219397==ERROR: AddressSanitizer: heap-use-after-free on address 0x6060010231a8 at pc 0x7ffae61b5cad bp 0x7ffa80d4ed80 sp 0x7ffa80d4e528 READ of size 41 at 0x6060010231a8 thread T87
0 0x7ffae61b5cac in __interceptor_fopen64 ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:5757
0x6060010231a8 is located 8 bytes inside of 64-byte region [0x6060010231a0,0x6060010231e0) freed by thread T94 here:
0 0x7ffae626d40f in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:122
previously allocated by thread T94 here:
0 0x7ffae626d808 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:144
Thread T87 created by T0 here:
0 0x7ffae619a815 in __interceptor_pthread_create ../../../../src/libsanitizer/asan/asan_interceptors.cc:208
Thread T94 created by T0 here:
0 0x7ffae619a815 in __interceptor_pthread_create ../../../../src/libsanitizer/asan/asan_interceptors.cc:208
It seems that the client's SSL resources are operated by two threads, causing a memory leak. 2 threads performing MQTTAsync_connect operations at the same time may cause the case, which is my usage fault maybe(When the connection is disconnected I will use connect instead of reconnect).
Looking forward to your reply, thank you.