Port the malloc lib to 2.9.1 #565
Comments
stieg
added a commit
that referenced
this issue
May 5, 2016
newlib was looking for this symbol because of the use of malloc, which was a requirement of vsnprintf and friends. This is not correct for RCP family since our malloc methods are handled by FreeRTOS. This patch addresses this issue by createing memory.c. These symbols override the malloc, free, realloc and calloc methods defined in libc, allowing us to use our own malloc methods instead of those provided by newlib. This in turn allows us to use a single malloc system as well as allows us to start using stdlib malloc, free, realloc and calloc like a proper program should instead of having to use portMalloc and portFree etc. This is a port from 2.10.0 to 2.9.1 since this is a stability patch. Issue: #565
|
Merged |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It seems we may have two allocators running on 2.9.0. One being the FreeRTOS one and the other being the glibc alloc. The latter is used by the
snprintffamily of methods, and seems to be only allocating very small amount of data, so that is probably why we didn't see any issues during testing. Regardless this is not good so a patch was developed to prevent the use of the libc malloc methods by overloading it with methods of the same name in our code and wrapping the FreeRTOS malloc calls.NOTE: These are not re-entrant safe methods, but since we don't alloc/free memory in any way in our ISRs, this shouldn't be an issue provided that the FreeRTOS malloc is thread safe (which I expect it to be).
The text was updated successfully, but these errors were encountered: