Am 06.03.2018 um 08:35 schrieb Michael Balzer:
Thanks for the crash report. It's not related to the esp-idf version. It occurs frequently if you're running low on memory (i.e. with many metrics and/or multiple web clients open in parallel), plus there's currently a race condition between metrics and event transfers. I'm already working on a solution for both.
I've pushed the update for the webserver to solve these issues. I've added some memory usage debug logs that can be activated by "log level debug webserver". The verbose level will give more detail but be a bit noisy now with a websocket running. It's harder now, but I still can crash it running out of memory by issueing a full "metrics list" in Twizy mode if hitting the right moment. The Twizy metrics dump needs ~9.4 kB: I (1699644) webserver: HTTP POST /api/execute I (1699644) webserver: HandleCommand: 31756 bytes free, executing: metrics list D (1699774) webserver: HandleCommand: 22300 bytes free, output size: 9383 bytes D (1699774) webserver: Serve /api/execute: 9672 bytes used, 22084 free This is now sent in 1K chunks, but the 22 kB free is a bit misleading. The command execution temporarily needs about double the size (once for the LogBuffers, once for the Dump() destination string). The 22 kB free is _after_ the Dump(), so LogBuffers already have been freed. At or below 20 kB of free RAM, the crash on "metrics list" is almost certain. I assume most of you don't get that low on free RAM and have smaller metrics sets, so this version should be stable for you. Please tell me if you're still encountering crashes. To avoid the second buffer of the command execution, I can add a chunked sender that directly reads the LogBuffers, so no Dump(string) is needed. But maybe there is a way to avoid even the LogBuffers. I'm thinking about an OvmsWriter that can write directly to a mongoose connection. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26