The onMqttMessage() handler copies the incoming MQTT message into a heap-allocated buffer, message, and calls delete[] message at the very end to deallocate this memory. However, there are early return statements that would trigger if either (a) setting the mode with an invalid mode string, or (b) taking any action that sets update = true but doesn't change a setting, like pushing a remote temperature reading.
In either case, onMqttMessage() will return without deallocating the message buffer, causing a memory leak. On an ESP-01, I found this to result in full memory exhaustion (as evidenced by an MQTT disconnect, persisting until the device was rebooted) every ~7.5 hours when submitting a remote temperature reading every 30 seconds.
This PR removes both return statements, replacing them with a logically equivalent control flow that ensures delete[] message is called in every case.
The
onMqttMessage()
handler copies the incoming MQTT message into a heap-allocated buffer,message
, and callsdelete[] message
at the very end to deallocate this memory. However, there are earlyreturn
statements that would trigger if either (a) setting the mode with an invalid mode string, or (b) taking any action that setsupdate = true
but doesn't change a setting, like pushing a remote temperature reading.In either case,
onMqttMessage()
will return without deallocating the message buffer, causing a memory leak. On an ESP-01, I found this to result in full memory exhaustion (as evidenced by an MQTT disconnect, persisting until the device was rebooted) every ~7.5 hours when submitting a remote temperature reading every 30 seconds.This PR removes both
return
statements, replacing them with a logically equivalent control flow that ensuresdelete[] message
is called in every case.