Nevermind. This was an illusion (as is usually the case when one suspects the compiler is misbehaving) caused by confusion between different IDF_PATH environments while testing the cases.

Sound like you're looking for uxTaskGetStackHighWaterMark() I am already using that call to get the minimum unused stack space. I need my hack to get the total stack space and current stack space to go with it, and I find it more convenient to show the maximum stack used (total - minimum) in my dis...

In my app I want to have a command that lists all the tasks in the system with the allocated stack size, amount of stack currently used, and the maximum stack used. I observed that uxTaskGetSystemState() does not set the pxStackBase member of the TaskStatus_t array, so I added the following hack cod...

To close the loop, this problem is being addressed in PR 1557.

Yes, the change to strcmp is the essence of the change. When I implemented this, I followed what was done in get_cached_log_level() to update the item generation as well, but I don't know important that is. I am attaching the diff of my change and will take your advice about whether the generation u...

If you try to set a different log level for a tag that has already emitted some log messages, the change won't take effect unless the tag string in the call is exactly the same const char* pointer as is used in the log messages. The problem is that the code only does a fast search of the cache, mean...

ESP_igrr wrote: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?

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 ...

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_d...

The reason why 84 bytes are not freed when you close the socket is that LWIP allocates a mutex for use with each socket structure the first time the socket is opened and intentionally does not free that mutex. Look for the comment /* one time init and never free */ in esp-idf/components/lwip/api/soc...