Thread safety of code generated by Cube

[unturned3]

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.

[unturned3]

Perhaps someone from ST can comment on this? What are we actually supposed to do right now?

[BarryWhit]

> 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?

That was a very long and unpleasant saga.

From what I've read through (also on Nadler's github issues, you should look it up), ST did address this. They years to do so, and the final result raised further questions. From what I gather "strategy 5" seemed to be ok, and "strategy 4" (fixed) was possibly ok. It is all very confusing, I agree. We all owe Nadler a thank you for identifying and explaining the issue, and then pressuring ST (not that it helped) to fix it. But as ST dragged their feet for years, Nadler got increasingly belligerent and unpleasant. I don't think this was much encouragement for the ST employee who tried to communicate ongoing status (nor would anyone else in their right mind willingly step into the rage pit that thread became) to continue to communicate with the vox populi directly.

There was a subsequent post by ST (same guy, who in my view was doing his best seeing as he's just an engineer in the corporate trenches) explaining the solution they deployed, which again had some backlash from Nadler, and that's pretty much where it's stood since then.

Nadler put his own solution on Github (Announcement post) and so far that seems to be the only fix whose functionality isn't shrouded in ambiguity and FUD.

I suspect no one at ST is eager to rekindle the bonfire in a public forum again, you may have more luck within the relative intimacy of an OLS ticket.

[unturned3]

Thanks for the clarification Barry! It seems like Nadler's solution should be preferred over ST's implementation for now... In your 2nd paragraph, you wrote "strategy 5" twice. I assume this is a typo?

I saw another approach to this issue in the book "Mastering STM32 - Second Edition" (page 616), which replaces all newlib malloc/free calls with the FreeRTOS-managed functions, so that all dynamic memory comes from the FreeRTOS heap:

This seems like a clean approach that modifies existing projects minimally. Perhaps there are some downsides to this method that I'm not aware of? It seems that pvPortMalloc can be used before the FreeRTOS scheduler starts, so early malloc calls wouldn't be a problem I assume?

[BarryWhit]

> In your 2nd paragraph, you wrote "strategy 5" twice. I assume this is a typo? 

Right, Fixed.

I can't speak from experience on your other question, I'll let someone else offer advice if they can.