This does not seem like a technical issue but rather awkward
usage/naming that is prone to misuse.
Yes, free() should be called to release the memory allocated by strdup.
But applications cannot use the kernel heap and, for reasons of
protection, the kernel should not store anything in the user-accessible
application heap in Protected mode. In Kernel mode, the application
heap may not even be available to OS without switching the address
environment.
So I think that a clean solution would be to fix the naming, either:
(1) rename the stdup used by the OS to kmm_strdup() with allocated
memory freed by kmm_free(), or (2) conditionally redefine free() to be
kmm_free() in the kernel portion of the build.
kmm_free() is already defined as free() in the FLAT build in
include/nuttx/kmalloc.h
On 9/21/2022 9:59 AM, Mark Stevens wrote:
So this post has been triggered by an issue I have just had using strdup in the
OS components of a protected mode build.
For clarity I will be using the term OS for the kernel part of the build and
application/app for the user part of the build.
The TLDR; is this design question:
Do we expect malloc and free to work with the relevant heaps? So for the OS
should they be working with the kernel heap and for apps they should be using
the user heap?
I am trying to work out if the problem is with strdup or with malloc & free.
Investigation / background
My understanding of strdup is that any string generated should have its memory
released using free, at least that is the way I have been using it for years.
The system under development uses a protected/kernel build with a memory
protection unit. We also have two heaps, one for the OS and one for the app.
At some point in the OS lifecycle we have the need to generate copies of
strings. These were generated using strdup. At some point in the future these
strings were released using free. At a point further in the future the system
crashed.
After some tracking it turns out that strdup was allocating memory using the
kernel heap (the strings were duplicated in the OS) and then freed in the OS
but the memory was being released to the user (Application) heap. When this
was then later allocated and used in user space the system would crash with a
memory fault.
Investigation points to the fact that strdup uses lib_malloc which will call
kmm_malloc in OS builds and malloc in app builds.
It also appears that malloc and free always work with the user heap.
I know that our build is a little old but looking at the sources this seems to
be the case with the current release. I am struggling to get the protected
build working on a F767 board to verify if the problem is still present.
Regards,
Mark
_____________________________
Blog: blog.thepcsite.co.uk
Twitter: @nevynuk
