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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev