esp_http_client appears to cause a memory leak in RTOS task

[sthivaios]

At this point I think the best approach is to make a bug report on github. There your problem will be seen by much more people from Espressif and they can have a look at the IDF code. I think it's recommendable that you assume the bug is in your code, but really, IDF is big and really, there are bugs in it. I've filed quite a few and most of them have been fixed

Thanks for helping out, yeah that's what I was planning to do next but I just wanted a few more opinions on it before blaming IDF. It's already at 63KB haha, it's definitely leaking faster now. Thanks again for the help I'll file an issue on the IDF repo and maybe link it here.

[MicroController]

At this point, I have 100% confirmed that what is causing this leak is this function, since in the task's code, when I comment out the line with the call to fetch_schedule_from_alim() the leak stops completely and the heap is stable.

If you don't do the HTTP call, I guess you don't have any JSON to parse/process either. Omitting the HTTP fetch directly changes other parts of the code flow.

You didn't show the rest of the code involved, you didn't share the heap tracing results, and you don't have a "minimum reproducible example". On this basis, the conclusion "it must be in the IDF" is too early to draw, and reporting an IDF bug with "I don't believe the code I don't show has a leak" doesn't seem quite warranted.

[eriksl]

I don't disagree, but I think the guys who wrote or maintain the IDF code can check very quickly if it's something there.

[MicroController]

If we had a heap trace showing just where allocations happened that weren't freed, that'd be indeed very easy. Without it, searching for an issue which may not even be there is laborious.

[eriksl]

Not necessarily. Every now and then I run into a similar vague bug in my own code and often just a dry code review already reveals the error. I hope this is a similar case.