[Ovmsdev] webserver (?) crash

Mark Webb-Johnson mark at webb-johnson.net
Wed Mar 21 08:34:24 HKT 2018


With 3.1, here is what I get on a clean boot:

OVMS# module memory
Free 8-bit 133180/282048, 32-bit 8164/24420, SPIRAM 4148396/4194252

And, again with 3.1, here it is after starting SIMCOM modem, wifi in APCLIENT mode, TR vehicle module, and Server v2:

OVMS# module memory
Free 8-bit 79520/282048, 32-bit 8164/24420, SPIRAM 4136036/4194252

OVMS# module tasks
Number of Tasks = 18       Stack:  Now   Max Total    Heap 32-bit SPIRAM
Task 3FFAEB34  1 esp_timer         392   648  6656   55140    644      0
Task 3FFAF7E0  2 eventTask         444  3116  4608    7620      0      0
Task 3FFC3F68  3 CanRxTask         420   420  4096       0      0      0
Task 3FFC8060  4 ipc0              396   444  1024   10848      0      0
Task 3FFC8660  5 ipc1              396   444  1024      12      0      0
Task 3FFCA488  8 IDLE              356   484  1024       0      0      0
Task 3FFCAA1C  9 IDLE              360   488  1024       0      0      0
Task 3FFCC3B0 10 Tmr Svc           396  3276  6144    7816      0      0
Task 3FFCF8F0 14 Housekeeping      364  2716  6144   53420      0      0
Task 3FFC8AB0 16 tiT               496  2752  6144    7112      0      0
Task 3FFD79C8 17 SIMCOMTask        452  2260  4096    4404      0      0
Task 3FFDB8C8 18 AsyncConsole      756  4964  5120   45864  15488      0
Task 3FFDCD84 19 mdns              416  1736  4096     108      0      0
Task 3FFE147C 20 wifi              424  2296  4096    5180      0      0
Task 3FFE3D74 21 pmT               416   464  2560       0      0      0
Task 3FFE6C30 22 NetManTask        732  2556  7168    2488      0      0
Task 3FFEAB08 23 Vrx Task          452   452  4096       0      0      0
Task 3FFEAD0C 24 OBDII ECU Task    424   424  6144       0      0      0

I think something got broken with a recent build of ESP-IDF so that our ‘module memory’ and ‘module tasks’ is not showing SPIRAM usage correctly. But, it is definitely used and certainly helps ease the stress:

OVMS# module memory
Free 8-bit 133032/282048, 32-bit 8164/24420, SPIRAM 4148396/4194252

OVMS# obdii ecu start can3
OBDII ECU has been started

OVMS# module memory
Free 8-bit 125000/282048, 32-bit 8164/24420, SPIRAM 4147772/4194252
--Task--     Total DRAM D/IRAM   IRAM SPIRAM   +/- DRAM D/IRAM   IRAM SPIRAM
AsyncConsole      13896   6144  15488      0      +1876  +6144     +0     +0

We are far from perfect, but I think good enough for some factory firmware. Anything else will come as OTA.

Regards, Mark.

> On 21 Mar 2018, at 3:12 AM, Michael Balzer <dexter at expeedo.de> wrote:
> 
> Am 20.03.2018 um 06:47 schrieb Greg D.:
>> Ok, interesting.  Am I seeing an out-of-memory crash?  I can't tell...
>> 
>> It seems like the webserver status button is the worst offender,
>> probably because it's doing a lot of work and building a big payload. 
>> Very often hangs for a while before responding, and if so, usually
>> results in the job queue overflow.  If I catch it quick enough and hit
>> home or some other shorter task, the overflow will drain and I'll get
>> the new screen; otherwise a crash.  Sometimes there will be a timeout
>> mixed in.  I'm wondering if our little squirrel in the ESP32 just can't
>> pedal hard enough...
> 
> Most crashes now are related to lack of free memory.
> 
> Regarding the status page I just hit the page 10 times:
> 
> OVMS# mo m
> Free 8-bit 27264/283200, 32-bit 27544/55820, SPIRAM 0/0
> I (784440) webserver: HTTP GET /status
> D (785010) webserver: Serve /status: 6068 bytes used, 21200 free
> I (787240) webserver: HTTP GET /status
> D (787830) webserver: Serve /status: 6064 bytes used, 21168 free
> I (788720) webserver: HTTP GET /status
> D (789290) webserver: Serve /status: 6104 bytes used, 21164 free
> I (790110) webserver: HTTP GET /status
> D (790700) webserver: Serve /status: 6100 bytes used, 21164 free
> I (791530) webserver: HTTP GET /status
> D (792120) webserver: Serve /status: 6068 bytes used, 21200 free
> I (792980) webserver: HTTP GET /status
> D (793550) webserver: Serve /status: 6100 bytes used, 21164 free
> I (794400) webserver: HTTP GET /status
> D (794980) webserver: Serve /status: 6068 bytes used, 21200 free
> I (795860) webserver: HTTP GET /status
> D (796730) webserver: Serve /status: 6100 bytes used, 21164 free
> I (797160) webserver: HTTP GET /status
> D (797740) webserver: Serve /status: 6064 bytes used, 21168 free
> I (798430) webserver: HTTP GET /status
> D (799020) webserver: Serve /status: 6060 bytes used, 21200 free
> OVMS# mo m
> Free 8-bit 27264/283200, 32-bit 27544/55820, SPIRAM 0/0
> 
> So no memory loss and no crashes.
> 
> The 6K is just the buffer usage after processing. The commands executed for the status page need additional RAM, but above 20 K free, the page normally has no
> problems.
> 
> Regards,
> Michael
> 
> -- 
> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
> 
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.teslaclub.hk/pipermail/ovmsdev/attachments/20180321/1668a980/attachment.html>


More information about the OvmsDev mailing list