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