Memory leak with wifi power up/down cycles

[slcasner]

I'm testing a telnet server over wifi. I'm repeatedly powering up wifi and bringing up the server, then taking them down again to check for memory leaks. I found there is one block lost each time. I've enabled CONFIG_ENABLE_MEMORY_DEBUG to facilitate this and I have added some code to heap_regions_debug.c to determine which task is responsible (it is the "wif" or wifi task) and which one of its sequence of allocations is the one that gets lost. Then I can induce an abort() in the mem_malloc_block() function when that allocation is done. After the abort, gdb shows me the following stack:

Code: Select all

#0  0x400893e8 in invoke_abort () at /Users/casner/src/github/esp-idf/components/esp32/./panic.c:138
#1  0x400894b6 in abort () at /Users/casner/src/github/esp-idf/components/esp32/./panic.c:147
#2  0x4008627a in mem_malloc_block (data=0x3ffeaa7c) at /Users/casner/src/github/esp-idf/components/freertos/./heap_regions_debug.c:208
#3  0x40085cda in pvPortMallocTagged (xWantedSize=<optimized out>, tag=<optimized out>)
    at /Users/casner/src/github/esp-idf/components/freertos/./heap_regions.c:308
#4  0x40089ae7 in pvPortMallocCaps (xWantedSize=13, caps=4) at /Users/casner/src/github/esp-idf/components/esp32/./heap_alloc_caps.c:372
#5  0x40089b28 in pvPortMalloc (xWantedSize=13) at /Users/casner/src/github/esp-idf/components/esp32/./heap_alloc_caps.c:306
#6  0x40081ff8 in _malloc_r (r=0x3ffdcedc, size=13) at /Users/casner/src/github/esp-idf/components/newlib/./syscalls.c:27
#7  0x4000beb2 in ?? ()
#8  0x4012bed8 in esp_wifi_vnd_lora_enable ()
#9  0x40135e40 in ieee80211_phy_init ()
#10 0x4012c278 in wifi_create_sta ()
#11 0x4012c367 in wifi_mode_set ()
#12 0x40132035 in wifi_start_process ()
#13 0x40132636 in ieee80211_ioctl_process ()
#14 0x40141c2e in ppTask ()

My debugging code also allows me to see that the content of all the leaked blocks is the same:

Code: Select all

  t=wif s=  40 a=0x3ffeaa2c  3FFEC464 81000028 09DD000B 0734FE18 20020001 00000021 1A2B3C4D 1A2B3C4D
  t=wif s=  40 a=0x3ffeaa04  3FFEC56C 81000028 09DD000B 0734FE18 20020001 00000021 1A2B3C4D 1A2B3C4D
  t=wif s=  40 a=0x3ffea9dc  3FFEC500 81000028 09DD000B 0734FE18 20020001 00000021 1A2B3C4D 1A2B3C4D
  t=wif s=  40 a=0x3ffeabec  3FFEAF28 81000028 09DD000B 0734FE18 20020001 00000021 1A2B3C4D 1A2B3C4D
The first two words are the header; the last two are the DOG value.  As the stack shows, the requested size is 13 bytes.  Those are:
09DD000B 0734FE18 20020001 21

Any idea what this is, or what the function in frame 7 actually is?

[ESP_igrr]

The function at frame 7 is probably 'malloc', and this looks like a bug in 'esp_wifi_vnd_lora_enable' (or the corresponding cleanup routine). Would you mind opening an issue on GitHub about this?
Thanks.

[slcasner]

I would be happy to file an issue for this, but before doing so I wanted to make sure the problem still existed with the latest SDK code rather than the snapshot of the master SDK that I pulled at the start of July and have been working with since then. I was also going to contribute back to a fork the heap debugging extensions I added to heap_regions_debug.c. Now I see that the heap implementation has been replaced so that file is not present any more. The old debug code that kept track of which task had made each allocation was very helpful for my debugging. Is there any chance that similar capabilities will be added to the new heap implementation?

It is possible that the issue with wifi failing to free memory has already been fixed in the current master SDK, so I should test first before filing the issue. I can still check if the overall free space is dropping, but I won't be able to tell if the cause is the same as before.

[ESP_igrr]

Is there any chance that similar capabilities will be added to the new heap implementation?

Yes, this such capability has been implemented and is currently in the merge queue. Expect it to be available on Github within a week.

[slcasner]

Yes, this such capability has been implemented and is currently in the merge queue. Expect it to be available on Github within a week.

I see the merges that were done for Release 2.1, but I don't see any heap debugging code added to esp-idf/components/heap/. Is this still in the merge queue?

[ESP_igrr]

Yes, still is.