[Ovmsdev] Revised memory diagnostics code

[Stephen Casner]

On Thu, 2 Nov 2017, Michael Balzer wrote:

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

Sorry for that oversight.  I did test compilation with memory
debugging off before the commit of the revised implementation, but I
did not do it again before last night's small change.  Shame, shame.
Thanks for fixing it.

> 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 vehicle
> + 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 vehicle
> + 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 vehicle
> + 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).

Not sure how you calculated 5608.  The total of the new blocks is
shown in the top section as +5556, so 5296 without debugging overhead.
I could change the code to subtract the size of the debugging
overhead; would that be a good idea?

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

The records are listed in the order they are queued in the OS.  Blocks
are added at the head pointer, hence the LIFO order.

When I first added some memory debugging a few months ago while trying
to figure where memory was leaking in the telnet implementation, I
included the display of the first 8 words of each block so I could
try to recognize the type of each block.

The first of the 8 words shown for each block is the "next" pointer,
so you can see how the blocks are chained.  In the second word, the
first digit '8' indicates the block is allocated and the second digit
0,1,2 indicates in which region of memory the block sits.  Both 0 and
1 are 8-bit accessible, while 2 is 32-bit accessible (IRAM).  For the
32-byte blocks we see the end "dog" in the 6th column and two overhead
words for the next block, the start "dog" and the taskid 3FFED17C, in
the 7th columns in the 8th.  For the stack you can see the fill value
A5A5A5A5 which is used to detect the maximum extent of the stack.

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

The three strings each hold the 7 characters "vehicle", as I have
edited on the end of the lines.  The 4th column is the pointer to the
text and the 5th column is the length (7).  The use of std::string
imposes quite a bit of overhead for these short bits of text.

                                                        -- Steve