lumapu
commented
3 months ago it is really similar to this issue:
Version 1.7.0 of this library is uesd
Closed lumapu closed 2 weeks ago
lumapu
commented
3 months ago it is really similar to this issue:
Version 1.7.0 of this library is uesd
bertmelis
commented
3 months ago Do you want to test before publishing packets or test before receiving packets?
Before placing new packets on the heap, a check is done with a configurable free heap value: https://github.com/bertmelis/espMqttClient/blob/main/src/Packets/Packet.cpp#L315
You could also the the new memory pool feature which automatically limits the amount of memory that is used by this lib. This is experimental however.
The numbers in your dump also don't seem to be correct. Default stack size for the mqtt task is only 5120.
bertmelis
commented
3 months ago Now that I'm thinking about it. I can check for free heap before writing out data. I suppose the underlying libraries (WiFiClient etc) also use heap memory to allocate the outgoing data buffers. I could add a check before trying to write like this:
// MqttClient.cpp line 353
int MqttClient::_sendPacket() {
// check before trying to send
if (EMC_GET_FREE_MEMORY() < EMC_MIN_FREE_MEMORY) {
return 0;
}
OutgoingPacket* packet = _outbox.getCurrent();
size_t written = 0;
if (packet) {
size_t wantToWrite = packet->packet.available(_bytesSent);
if (wantToWrite == 0) {
return 0;
}
written = _transport->write(packet->packet.data(_bytesSent), wantToWrite);
packet->timeSent = millis();
_lastClientActivity = millis();
_bytesSent += written;
emc_log_i("tx %zu/%zu (%02x)", _bytesSent, packet->packet.size(), packet->packet.packetType());
}
return written;
}Ideally, the underlying libraries don't crash on low memory but accept the situation and return some sensible value.
lumapu
commented
3 months ago Thank you for your answers. What happens if I set EMC_USE_MEMPOOL 1, the pool reaches its full status and I try to send out packets? Am I right that I will get 0 as return value of publish(...)?
bertmelis
commented
3 months ago Yes, the same thing will happen like when you are running out of regular heap: publish will return 0.
The pool only tries to prevent heap fragmentation and puts a stricter limit on memory usage. Mind that the pool itself still has fragmentation (although it will be less). And only limited real world testing has been done so beware...
ajen2420
commented
2 weeks ago I solve this problem by setting a condition that if there is connection with mqtt server then it will publish a message. Simple I tested it with esp32 uptime 3days.. Can be more obviously.
Do not use to discuss topics!
Describe the bug The ESP32 crashes from time to time once Wifi is very poor but data has to be sent continously.
Which platform, esp8266 or esp32?
Bug report (ESP - Coredump, captured from coredump-partition)
Coredump
``` =============================================================== ==================== ESP32 CORE DUMP START ==================== Crashed task handle: 0x3ffbd4d4, name: '', GDB name: 'process 1073468628' ================== CURRENT THREAD REGISTERS =================== exccause 0x1d (StoreProhibitedCause) excvaddr 0x0 epc1 0x40146c11 epc2 0x0 epc3 0x0 epc4 0x0 epc5 0x40082e0e epc6 0x0 eps2 0x0 eps3 0x0 eps4 0x0 eps5 0x60720 eps6 0x0 [New process 1073468628] [New process 1073548364] [New process 1073460608] [New process 1073427564] [New process 1073443660] [New process 1073601224] [New process 1073445360] [New process 1073431632] [New process 1073436104] [New process 1073610016] [New process 1073605768] [New process 1073447304] [New process 1073409856] [New process 1073466120] [Current thread is 1 (process 1073468628)] ==================== CURRENT THREAD STACK ===================== ======================== THREADS INFO ========================= pc 0x40083cb4 0x40083cb4Expected behaviour ESP has an endless uptime
To Reproduce Not that easy. Keep the ESP as far as possible from you WiFi an send continuously data from it to a broker. Depending on the environment the quality changes and on some reason the heap runs out of memory.
Example code https://github.com/lumapu/ahoy/tree/development03
Additional context My idea is to have like a monitor running which checks whether it is possilbe to accept messages to be transfered depending on free heap. It would be nice to have some kind of threshold which can be configured (maybe 0 as default, then the current behaviour won't change). I can try to implement this q'n'd in my surronding
publishmethod and test it. I have one ESP which shows this issue almost every day.