[Ovmsdev] Revised memory diagnostics code

Michael Balzer dexter at expeedo.de
Thu Nov 2 18:20:58 HKT 2017 

I've added a small fix to reenable building without memory debugging.

The base footprint of a vehicle module is…


OVMS > vehicle module NONE
I (31916) v-none: Generic NONE vehicle module
OVMS > module memory AsyncConsole
============================
Free 8-bit 35536/217576, 32-bit 16680/43464, blocks dumped = 18
task=AsyncConsole    total=      0   5556  26120 change=     +0 
+5556     +0
task=tiT             total=    288   1080      0 change=     +0   
+52     +0
============================
  t=AsyncConsole s= 920 a=0x4009bb34  4009BAF8 82000398 3FFED17C
00000000 00000000 00006608 00000000 000015B4
  t=AsyncConsole s=  60 a=0x4009baf8  4009B6AC 8200003C 3FFED17C
F1E5C23B CD106DF9 9CE8BA4A 3BAEA0BA CEC251D4
  t=AsyncConsole s=1100 a=0x4009b6ac  400987B8 8200044C 3FFED17C
3FFED1B4 00000011 00000001 00000005 00000005
  t=AsyncConsole s=12020 a=0x400987b8  400958C4 82002EF4 3FFED17C
3FFEDCB0 01000034 3FFED17C 3FFED968 01000030
  t=AsyncConsole s=12020 a=0x400958c4  3FFF6494 82002EF4 3FFED17C
4009BB34 02000398 3FFED17C 4009BAF8 0200003C
----------------------------
+ t=AsyncConsole s=  52 a=0x3ffedcb0  3FFED968 81000034 3FFCF230
3FFCF37C 3FFEDC78 1A2B3C4D 1A2B3C4D 3FFDD7B8
+ t=AsyncConsole s=  48 a=0x3ffed968  3FFEDC70 81000030 40193328
00000000 3FFED5D4 BF2C7602 0064D3E9 ADBEEF00
+ t=AsyncConsole s=  64 a=0x3ffedc70  3FFED948 81000040 3F40A9A8
3FFEDC84 00000007 69686576 00656C63 3A6D6F63
+ t=AsyncConsole s=  32 a=0x3ffed948  3FFED928 81000020 3FFCF2FC
3FFCF45C 3FFED8F0 1A2B3C4D 1A2B3C4D 3FFED17C
+ t=AsyncConsole s=  32 a=0x3ffed928  3FFED8E8 81000020 40193328
00000000 3FFED5D4 1A2B3C4D 1A2B3C4D 3FFED17C
+ t=AsyncConsole s=  64 a=0x3ffed8e8  3FFED890 81000040 3F40A9A8
3FFED8FC 00000007 69686576 00656C63 01742513
+ t=AsyncConsole s=  48 a=0x3ffed890  3FFED7E4 81000030 3FFE3140
3FFE3220 3FFED858 00E00409 BEEFFB00 3FFCDEAD
+ t=AsyncConsole s=  56 a=0x3ffed7e4  3FFED850 81000038 400ECED8
00000000 3FFED5D4 40173E7C 00000000 00BBA54A
+ t=AsyncConsole s=  64 a=0x3ffed850  3FFF75B0 81000040 3F40A9A8
3FFED864 00000007 69686576 00656C63 0038001A
+ t=AsyncConsole s= 380 a=0x3fff75b0  3FFF659C 8100017C 3FFF73E0
3FFF7540 F121C6CB 3FFD6E54 3FFC2FF0 3FFF75B8
+ t=AsyncConsole s=4116 a=0x3fff659c  3FFF6094 81001014 A5A5A5A5
A5A5A5A5 A5A5A5A5 A5A5A5A5 A5A5A5A5 A5A5A5A5
+ t=AsyncConsole s= 504 a=0x3fff6094  3FFED5CC 810001F8 3FFF60F0
3FFF6280 3FFF60F0 3FFF626C 00000000 3FFF60B4
+ t=AsyncConsole s=  96 a=0x3ffed5cc  4009BB34 81000060 3F408088
00000000 00000000 00000000 3FFF609C 3FFF75B8
============================


… 5608 bytes (5328 w/o debugging overhead).

It seems the list output is sorted LIFO, i.e. the 96 byte allocation
(sizeof(OvmsVehicle) + 20) was the first here.

The 504 (484) block is the CAN rx queue, the 4116 (4096) & 380 (360)
bytes are the CAN rx task stack & control structs.

The small allocations following seem to be some std::strings, haven't
tracked them down yet. Not all of them get freed on unloading the
vehicle module.


Regards,
Michael


Am 02.11.2017 um 06:27 schrieb Stephen Casner:
> Some more info about the revised memory diagnostics.
>
> You can get a list of blocks owned by any of the tasks by specifying
> one or more task names or ids on the module memory command.  The
> output shows the task name, block size, block address, and the eight
> words of the block (the first two being the malloc header):
>
> OVMS > module memory wifi
> ============================
> Free 8-bit 64132/245712, 32-bit 16648/43432, blocks dumped = 10
> ============================
>   t=wifi s= 180 a=0x3ffe67c0  3FFE670C 810000B4 00000002 00000000 00000000 00000000 00000000 00000000
>   t=wifi s= 180 a=0x3ffe670c  3FFE643C 810000B4 00000006 00000000 00000002 00000000 00000000 00000000
>   t=wifi s=  56 a=0x3ffe643c  3FFE63E8 81000038 00000000 00000000 00000000 00000000 00000000 00000000
>   t=wifi s=  84 a=0x3ffe63e8  3FFE64D4 81000054 00000006 00000000 00000000 00060004 00000000 00000004
>   t=wifi s= 620 a=0x3ffed240  3FFED068 8100026C 3FFED070 FFFFFFFF 0000FFFF 00000000 00000000 00000000
>   t=wifi s= 472 a=0x3ffed068  3FFED7EC 810001D8 00000000 FFFFFFFF 033A0279 00000000 401467AC 00000000
>   t=wifi s= 104 a=0x3ffed7ec  3FFECE78 81000068 00000000 00000000 3FFED7F4 00000000 00000000 3FFED80C
>   t=wifi s= 380 a=0x3ffece78  3FFEC064 8100017C 3FFECCD0 3FFECE00 5320B35D 3FFD00C8 3FFCC0D4 3FFECE80
>   t=wifi s=3604 a=0x3ffec064  3FFEBFAC 81000E14 A5A5A5A5 A5A5A5A5 A5A5A5A5 A5A5A5A5 A5A5A5A5 A5A5A5A5
>   t=wifi s= 184 a=0x3ffebfac  3FFEBF44 810000B8 3FFEC008 3FFEC058 3FFEC010 3FFEC00C 00000000 3FFEBFCC
> ============================
>
> If this command is given before and after some action then the later
> result will separate the blocks into three lists: those freed since
> the previous command, those that are still allocated, and those that
> have been newly allocated since the previous command.  These are
> prefixed by '-', ' ', and '+', respectively.
>
> The "blocks dumped" value on the first line of the output tells how
> many blocks were found when the command was issued.  The space set
> aside to receive the list of blocks (allocated from 32-bit IRAM) is
> limited to 1000 blocks.  If that limit is hit then some blocks will
> not be shown.
>
> In the previous implementation of the memory diagnostics, the blocks
> for all tasks were dumped from the OS to the app storage and the total
> space for each task was calculated in the app.  Hence, if there had
> been more than 1000 blocks allocated the totals would not be correct.
> There was an example of this in Mark's message about RAM use for
> metrics structures:
>
>> OVMS > module memory
>> ============================
>> Free 8-bit 85800/246632, 32-bit 18576/43548, numafter = 1000
> In the revised implementation the totaling is done in the OS and
> reported to the app separately from the list of blocks, and only the
> blocks belonging to the selected tasks are returned.  That should make
> hitting the limit less likely.
>
>                                                         -- Steve
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

More information about the OvmsDev mailing list