[Ovmsdev] 3.1.005

[Michael Balzer]

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 at 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