Folks,
I am debugging a memory leak in my code, and so far has not managed to isolate the main cause. I am using standalone heap tracing mode. In addition to heap tracing, I am recording available heap memory at the start and at the end of the code block.
Here is one of the examples I would like to understand. Notice that heap memory has not changed:
I (117862) app: heap1=116232 heap2=116232
However heap tracing reports the following:
5 allocations trace (1000 entry buffer)
16 bytes (@ 0x3ffd4e70) allocated CPU 0 ccount 0x5d48f7f8 caller 0x400e850c:0x400e8596:0x400e85fc:0x400eefe4:0x400ef074:0x400ef198:0x400e69c1:0x400e6a73:0x4008dcc0:
0x400e850c: mem_malloc at /mnt/data/electronics/microcontrollers/esp32/esp-idf/components/lwip/lwip/src/core/mem.c:237
0x400e8596: do_memp_malloc_pool at /mnt/data/electronics/microcontrollers/esp32/esp-idf/components/lwip/lwip/src/core/memp.c:254
0x400e85fc: memp_malloc at /mnt/data/electronics/microcontrollers/esp32/esp-idf/components/lwip/lwip/src/core/memp.c:350 (discriminator 2)
0x400eefe4: sys_timeout_abs at /mnt/data/electronics/microcontrollers/esp32/esp-idf/components/lwip/lwip/src/core/timeouts.c:199
0x400ef074: lwip_cyclic_timer at /mnt/data/electronics/microcontrollers/esp32/esp-idf/components/lwip/lwip/src/core/timeouts.c:271
0x400ef198: sys_check_timeouts at /mnt/data/electronics/microcontrollers/esp32/esp-idf/components/lwip/lwip/src/core/timeouts.c:409
0x400e69c1: tcpip_timeouts_mbox_fetch at /mnt/data/electronics/microcontrollers/esp32/esp-idf/components/lwip/lwip/src/api/tcpip.c:117
0x400e6a73: tcpip_thread at /mnt/data/electronics/microcontrollers/esp32/esp-idf/components/lwip/lwip/src/api/tcpip.c:149
0x4008dcc0: vPortTaskWrapper at /mnt/data/electronics/microcontrollers/esp32/esp-idf/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:143
The same message continues for a few screens, and then:
80 bytes 'leaked' in trace (5 allocations)
total allocations 149 total frees 148
Does anyone know what are these?
Thanks.
debugging a memory leak
Re: debugging a memory leak
I found one memory leak in setenv("TZ"...) calls when using tzset to switch between different timezones. I keep printing available heap memory, and so far I don't see any decrease in available heap.
Re: debugging a memory leak
Just to confirm, switching between timezones using calls to setenv() and then tzset() ate all available heap memory on esp32 module in about 24 hours. Getting rid of that code solved the problem for me.
Who is online
Users browsing this forum: No registered users and 62 guests