[Ovmsdev] Memory leak

[Mark Webb-Johnson]

I’d like to keep the core memory allocation stuff in ovms.h. It is used pretty much everywhere, and it is good to keep it easily available.

I’ve committed the change, just now.

Regards, Mark.

> On 23 Apr 2018, at 2:19 PM, Michael Balzer <dexter at expeedo.de> wrote:
> 
> Mark,
> 
> I separated it out of modularity concerns (ovms.h = tools, ovms_extram.h = apps) and thought it may also gain some compile speed when we add more std headers to
> _extram.h.
> 
> Currently that speed gain is near null, because it's included now by _utils.h, but that include can possibly be replaced by a forward declaration of extram::string.
> 
> But I don't object if you think it's better to have this in one place.
> 
> Regards,
> Michael
> 
> 
> Am 23.04.2018 um 04:07 schrieb Mark Webb-Johnson:
>> Michael,
>> 
>> Do we need ovms_extram.h? Can we just put the namespace directly into ovms.h (where all the other external ram allocation stuff is)?
>> 
>> Regards, Mark
>> 
>>> On 22 Apr 2018, at 10:28 PM, Michael Balzer <dexter at expeedo.de> wrote:
>>> 
>>> I could reproduce the situation, it was caused by a combination of…
>>> 
>>> (a) the modem being captured in an endless reconnect retry loop
>>> (b) the notifications, still being allocated from internal RAM, adding up while server.v2 waits for the connection
>>> 
>>> I have pushed a solution for (b) and an attempt for (a) -- couldn't test that yet.
>>> 
>>> The effect of (a) is the modem only answers "ERROR" to the +CGDATA="PPP" command. I have tried different commands to reset the internal state, but it was stuck,
>>> only a power cycle could solve this. I have added an automatic power cycle for this situation, but it didn't occur again yet.
>>> 
>>> The solution for (b) is to move the notifications buffer to external RAM. As that went without any problems, I also moved the command and server communication
>>> buffers to external RAM, which also went without problems.
>>> 
>>> In action:
>>> 
>>> … (sending 15 battery data notifications) …
>>> I (645344) ovms-server-v2: Send MP-0 h70,1,RT-BAT-C,14,86400,2,1,4105,4105,4105,10,15,15,15,0
>>> OVMS# mo m
>>> Free 8-bit 57692/281968, 32-bit 8052/24308, SPIRAM 4124384/4194252
>>> --Task--     Total DRAM D/IRAM   IRAM SPIRAM   +/- DRAM D/IRAM   IRAM SPIRAM
>>> OVMS Events       53012  49124      0  12604         +0     +0     +0  +1768
>>> … (receiving 15 acks) …
>>> I (648804) ovms-server-v2: Incoming Msg: MP-0 h70
>>> OVMS# mo m
>>> Free 8-bit 57692/281968, 32-bit 8052/24308, SPIRAM 4125488/4194252
>>> --Task--     Total DRAM D/IRAM   IRAM SPIRAM   +/- DRAM D/IRAM   IRAM SPIRAM
>>> OVMS Events       53012  49124      0  10836         +0     +0     +0  -1768
>>> 
>>> 
>>> I have added a C++11 allocator template "ExtRamAllocator" for this, which can be used for all allocator-aware standard classes. "ovms_extram.h" provides a
>>> namespace "extram" for std type instances using the allocator. It now has "string" and "ostringstream", please add further types as needed.
>>> 
>>> @Steve: I would like to keep the allocation/task ownership info for now, I think it's worth the overhead.
>>> 
>>> 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.openvehicles.com
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>> _______________________________________________
>> 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
> 
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev