2024-06-29 2:52 PM - edited 2024-06-29 3:56 PM
Hello,
I'm wondering if Cube's generated code for is thread safe. In particular, whether malloc can be safely used in a multi-threaded FreeRTOS setup.
The broken malloc behavior was first described by Dave Nadler in 2019 here. He has also written about it on his webpage.
In 2021, ST seems to have introduced some "fixes" to this problem, by adding a thread-safe code generation option in CubeMX and implementing the various __retarget_lock* newlib functions to make sure that newlib can behave correctly in a multi-threaded environment.
However, it seems like that these implementations are buggy. One such issue is reported here, where the lock's nesting level is (incorrectly) modified before entering the critical section. I've just reproduced this exact issue today, with Cube version 6.11.1.
I'm quite confused about the current state of this issue. Are the things described by Dave Nadler still relevant or applicable? Is ST going to fix the bugs in the __retarget_lock* implementations? For people using Cube's generated code, how are you all dealing with this at the moment?
In addition, is there a central bug tracker somewhere that we can use to keep track of such problems? This seems like a catastrophic issue, but information about it is scattered everywhere across random webpages and forum discussions.
Thank you.
2026-01-12 8:56 AM
Oh wow, thanks! Looking forward to the release.