You are not logged in. Please login or register.
Please post questions or comments you have about wolfSSL products here. It is helpful to be as descriptive as possible when asking your questions.
ReferenceswolfSSL - Embedded SSL Library → wolfMQTT → Shutdown required?
I am trying to track down a memory leak that occurs every time wolfSSL tries to reconnect after the socket connection with a sever was lost. I am not an expert, so I ask: Should MqttSocket_Disconnect() within mqtt_socket.c also contain a call to wolfSSL_shutdown()?
Hello @kackle123
Thanks for contacting wolfSSL Support. Calling wolfSSL_shutdown is not required, since the broker will disconnect the socket connection after the client sends the disconnect packet (MqttClient_Disconnect). The wolfSSL resources are freed using the code in MqttSocket_Disconnect:
https://github.com/wolfSSL/wolfMQTT/blo … ket.c#L465
Could there be an allocation in the application TLS setup callback? In the examples, we use mqtt_tls_cb
https://github.com/wolfSSL/wolfMQTT/blo … ple.c#L505
Thanks,
Eric @wolfSSL Support
Thank you, Eric, for your reply.
I think it's the server that is initiating the disconnect from my wolfMQTT client. Wouldn't that leave a wolfSSL socket hanging?
I did not explicitly use mqtt_tls_cb(), and after a code search, I don't see it being utilized by wolfSSL nor wolfMQTT.
The socket is closed (in the example code) by mqttexample.c::NetDisconnect, which is called from mqtt_socket.c::MqttSocket_Disconnect
https://github.com/wolfSSL/wolfMQTT/blo … ket.c#L480
There are not a lot of mallocs in the library proper, so it should be possible to use a memcheck tool to find the culprit. We sometimes use valgrind to hunt for mem leaks.
Since MqttSocket_Disconnect() is in wolfMQTT's library, wouldn't that still leave any wolfSSL socket resources allocated? Or does wolfMQTT tell wolfSSL to free its socket resources somehow? Since I can find no calls to wolfSSL_shutdown() anywhere in the wolfMQTT or wolfSSL libraries, what's the point of that function in the first place?
This is an embedded project, so I don't know how I would use Valgrind. wolfMQTT itself has only a couple of mallocs and my manual debugger tracing showed me they are handled correctly. But there are dozens within wolfSSL and it eats more memory upon every re-connection.
The socket handling is the responsibility of the application's implementation of the MqttNet structure. The example does this here:
https://github.com/wolfSSL/wolfMQTT/blo … et.c#L1048
The wolfSSL_shutdown API is used to send the FIN packet to a peer, indicating that the application will no longer listen to that socket. The wolfSSL_shutdown API is used by the client as part of a bi-directional shutdown, but otherwise is not needed at the client side. It does not clean up the socket resource.
There is built-in memory tracking in wolfSSL:
-DWOLFSSL_TRACK_MEMORYor
./configure --enable-trackmemoryAlso memory logging:
-DWOLFSSL_MEMORY_LOGor
--enable-memorylogRegarding the wolfSSL_shutdown(), I see.
About the memory flags, I am rather unfamiliar with using such flags in my embedded environment (an NXP K22 128 kB RAM, using their CodeWarrior IDE). Am I able to, or are these for full operating systems? And what do these do for me; I find no documentation.
I saw that there were memory leak fixes made in wolfSSL. I am going to try using this latest version.
wolfSSL - Embedded SSL Library → wolfMQTT → Shutdown required?
Powered by PunBB, supported by Informer Technologies, Inc.
Generated in 0.017 seconds (89% PHP - 11% DB) with 9 queries