[Ovmsdev] Memory leak

[Stephen Casner]

I did a little experiment.  I added code in Housekeeping
initialization to allocate and close a socket 10 times.  That does add
storage for 10 88-byte blocks to the Housekeeping task, but it does
not change the memory allocated to the two no-longer-existing tasks:

Free 8-bit 31148/283136, 32-bit 27588/55864, SPIRAM 0/0
--Task--     Total DRAM D/IRAM   IRAM SPIRAM   +/- DRAM D/IRAM   IRAM SPIRAM
3FFE5CDC              0   1396      0      0         +0  +1396     +0     +0
3FFEB408              0    264      0      0         +0   +264     +0     +0

This is with the mdns task back in operation and still existing, so
those are not it.

And I see in our codebase that we only create two tasks with an
explict call to xTaskCreatePinnedToCore() rather than through
TaskBase.  One is Housekeeping, which already has a call to
AddTaskToMap() after it.  The second is NetManTask.  Now I have I
added a call to AddTaskToMap() after that one as well, and that lets
me see that the task with 264 bytes allocated was an earlier instance
of NetManTask that was killed.  With that call in place, we see two
instances of NetManTask in the module memory output:

Free 8-bit 31308/283136, 32-bit 27588/55864, SPIRAM 0/0
--Task--     Total DRAM D/IRAM   IRAM SPIRAM   +/- DRAM D/IRAM   IRAM SPIRAM
no task            5276      0      0      0         +0     +0     +0     +0
esp_timer         55112      0    644      0         +0     +0     +0     +0
main              39948      0      0      0         +0     +0     +0     +0
ipc0              10848      0      0      0         +0     +0     +0     +0
Housekeeping      17508  50496      0      0         +0     +0     +0     +0
tiT                 148   1624      0      0         +0     +0     +0     +0
ipc1                 12      0      0      0         +0     +0     +0     +0
wifi                 36   1572      0      0         +0     +0     +0     +0
mdns                  4    104      0      0         +0     +0     +0     +0
Tmr Svc               0  28240      0      0         +0     +0     +0     +0
3FFE5D08              0   1396      0      0         +0     +0     +0     +0
NetManTask            0    264      0      0         +0     +0     +0     +0
AsyncConsole          0     20  27488      0         +0     +0     +0     +0
NetManTask            0   2204      0      0         +0     +0     +0     +0
eventTask             0   7620      0      0         +0     +0     +0     +0

The task with 1396 bytes allocated may be something related to the
first instance of NetManTask that also gets killed.

                                                        -- Steve

On Mon, 19 Mar 2018, Stephen Casner wrote:

> On Mon, 19 Mar 2018, Michael Balzer wrote:
>
> > I've seen some allocations looking like memory leaks but getting
> > freed after a minute or two. I assume those are mongoose buffers or
> > LWIP socket structs getting freed after some timeout.
>
> These hang around for at least 5 minutes.  But some of these
> allocations are 88-byte blocks that could be from LWIP allocating
> mutexes for socket management.  Those are explicitly never freed.  The
> following comment precedes the allocation statement:  /* one time init
> and never free */ LWIP appears to use a fresh socket structure each
> time until all of the sockets in the preconfigured array have been
> used.  The default value is 10 sockets.
>
> > I start dynamic tasks primarily for web command execution in
> > streaming mode. The "vfs tail" command also runs as a dynamic task.
>
> That should be covered by the use of TaskBase, as I mentioned in the
> previous email.
>
> > If you had the mDNS component still active, that could also be the cause.
>
> This was after mDNS was disabled.
>
>                                                         -- Steve
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev