Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Task memory leaking after 0.0.1-134-gb83c262 #564

Open
linuxforum5 opened this issue Feb 11, 2018 · 1 comment
Open

Task memory leaking after 0.0.1-134-gb83c262 #564

linuxforum5 opened this issue Feb 11, 2018 · 1 comment

Comments

@linuxforum5
Copy link

The vTaskDelete() is not freeing all unused memory.
This is the sample code:
heaptest.c.txt

The free heap is constant (43692) in version 0.0.1-134-gb83c262.
screen.log.0.0.1-134-gb83c262.txt

Memory leaks in version 0.0.1-163-g546cc47 and in further versions.
screen.log.0.0.1-260-g5f8b3d4.txt

@ourairquality
Copy link
Contributor

Thank you for the report. A first guess would be to look at the newlib integration into FreeRTOS. On a task being deleted it should call back into newlib to free up the newlib resources, and FreeRTOS calls _reclaim_reent() in libc/reent/reent.c

It might be that some of the I/O resource are not being freed. Some of these might be allocated in newlib/libc/stdio/findfp.c and there is a clean up function too.

I doubt there was anything in the commit you noticed that caused this apart from simply enabling the FreeRTOS integration with newlib which was essential. We will just have to work through it to get it freeing the resources properly.

Have you tried simply closing the stdin stdout and stderr FILEs before deleting the task to see if that solves this problem, or reduces the amount leaked?

Newlib also has an option to use global streams, and that might be another option to explore.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants