pvint
commented
3 years ago Original comment by Paul Vint (Bitbucket: pvint, GitHub: pvint).
I’m having trouble tracing back to see why it’s trying to remove it twice, so for now I’ve done this:
340a341
>
342,348c343,344
< if(_tcpClients[i] != NULL) {
< _tcpClients[i]->free();
< _tcpClients[i] = NULL;
< }
< else {
< DEBUG_MSG_FAUXMO("[FAUXMO] Client %d already disconnected\n", i);
< }
---
> _tcpClients[i]->free();
> _tcpClients[i] = NULL;
This seems to be functioning fine.
For reference, I’m using this in an esp-idf project, specifically: https://github.com/pvint/Starfish-idf/blob/master/main/starfish_main.cpp and it’s been controlling the lighting on my boat for a couple years. This is really a great project, and thanks!
Paul
Tejas-MD
Original report by Paul Vint (Bitbucket: pvint, GitHub: pvint).
I’ve been having occasional crashes for months, and I had thought it was taken care of when I updated AsyncTCP, but it has come back, but today I was lucky to have a consistent way to reproduce it and got some info.
Right now, if I tell Alexa “Turn on White Lights”, it sends commands to turn on fauxmo devices 0,1 and 2 (which actually works), however when fauxmo is closing connections and cleaning up, it is trying to call
_tcpClients[0]->free();an extra time for device 0 (zero). (Tested with 2nd gen and 3rd gen Echo Dot with same results)Here is my console output when it occurs (I added a couple printf statements in fauxmoESP.cpp and AsyncTCP.cpp for more info), along with a backtrace:
(The
I (12337) starfish: fauxmo device_id = 1 state = 1 val = 255 v = 4080lines are from my software showing where it receives info from fauxmoESP)
The critical part seems to be:
Note that near the end, it frees client 0, then client 1, and then tries to free client 0 again.
Debugging statements I added around line 343 in fauxmoESP.cpp:
I’ll keep digging and update as I have more info.
Thanks