Steve, no, both problems occurred in server v2 transmissions, with no SSH connections active. Not sure about active webserver connections. I took care to use chunked transfers with small buffers in there, but if multiple commands are fired in parallel, each takes its own stack. The normal web UI does not do that though. Regards, Michael Am 01.05.2018 um 21:32 schrieb Stephen Casner:
On Tue, 1 May 2018, Michael Balzer wrote:
The crash reports I got are RAM related. I don't know yet how this can still happen, one was a failed "new" operator in server_v2 for the message encryption, the other a failed mongoose buffer resize. Both modules should have plenty of free RAM now in about any situation, so I'm a bit clueless about these. Did this mongoose buffer problem occur on an ssh connection? It is still possible to use up a 4MB of RAM on a command that is generating output without being dependent on some source timing. For example, I expect that the "test chargen" command can still gobble up all the memory. It won't crash, though, because I added the error status plumbing necessary to avoid it and a check for the error in test_chargen.
If you want to test with with the v3.1 module, I suggest unmounting the SD card first in case you need to reboot ungracefully, then try:
test chargen 1000000
What I expect to happen is that a few hundred lines of output will be printed and then an error message will be logged on the async console, followed some time later by messages on the ssh console and the async console about characters lost.
-- Steve _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26