bertmelis
commented
10 months ago This needs further investigation. The memory check is very crude. Of course, there is a slight difference between the memory check and the actual memory afterwards but I definitely not expect it to be 3k.
There might be a bug indeed. A queue item is created here.
Node* node = new (std::nothrow) Node(std::forward<Args>(args) ...);
if (node != nullptr) {The Node constructor is here:
explicit Node(Args&&... args)
: data(std::forward<Args>(args) ...)
, next(nullptr) {
// empty
}Here, the node in the queue can exist but it's data can be non existent. The error is set but the node is not cleared. Later, when trying to send the data, it fails.
Here might be the problem:
if (it && error == espMqttClientTypes::Error::SUCCESS) return true;
return false;ON failure it just returns false instead of cleaning up the node at iterator.
MichaelDvP
I'm not sure if this is really a bug or i understand something wrong. In proddys emsesp-project some users reports freezing which is (maybe) related to the mqtt at low memory when mqtt is disconnected, With old asyncMqttClient we delete old queued messages when getFreeHeap goes below 60k. In espMqttClient there is the EMC_MIN_FREE_MEMORY setting. Discussion about that is here
I've tested with a modifcated https://github.com/bertmelis/espMqttClient/blob/main/examples/notask-esp32/notask-esp32.ino, and added in loop:
(BTW: currentMillies should not be static to update it in every loop)
config.h
helpers.h
(BTW: the mem-check for PSRAM is critical, the esp32 default in sdkconfig.h is CONFIG_SPIRAM_MALLOC_ALWAYSINTERNAL=4096, so mqtt publish is mainly allocated in internal ram. Better check both RAM for enough space)
With the above settings on a esp32/4M, nodemcu (no PSRAM) i get an output:
which looks as expected, except the allocation fail is at 53k,not at 60k. with debug messages i see that allocation fails at 60k, but publish gives back a valid message-id and free heap is still going down.
Some messages later strange things happens:
and at last, when heap is down at 53k the message-Id is returned as zero and no log messages from the client
Testing the same with a own task is similar, but some with some other events: log_with_own_task.txt
Workaround is not to use EMC_ALLOW_NOT_CONNECTED_PUBLISH, or stop feeding publishes on an own memory limit higher than the setting in the library. Your solution not to allocate mem for the new messages is not ideal, better is to delete the oldest message in the queue and queue the new message. Is there a way to delete the oldest message in queue by a function call? I've added a getQueueSize to check the queued messages, but in case of disconnected mqtt memory is allocated but the outbox does not grow. Is there a better way to read the number of messages in the queue?