BUG: CubeMX FreeRTOS projects corrupt memory

[Dave Nadler]

Typical user symptom: sprintf with floating point doesn't work or crashes.

I've provided a complete explanation and required fixes here:

http://www.nadler.com/embedded/newlibAndFreeRTOS.html

To illustrate the crash in minimal test application, I've provided this example project ready to run for a Nucleo 429:

http://www.nadler.com/embedded/20190804_STM_malloc-Kaboom_demo.zip

Set breakpoints at:

sysmem.c: on the line with errno = ENOMEM;

main.c, in default task, on line kaboomP1 = malloc(16);

Enjoy the fireworks.

Comments on (one of) the problems are provided in sysmem.c

The fixes are explained in the web page linked above, and illustrated in this corrected minimal project:

http://www.nadler.com/embedded/20191115_malloc-Kaboom_fixed.zip

It would be great if STM could:

- confirm they understand this set of bugs

- fix them in a prompt release of ST32cubeIDE/CubeMX/etc.

OK, we can dream, right?

Thanks,

Best Regards, Dave

[Markus GIRDLAND]

We are aware as this has always been an issue in TrueSTUDIO as well. The set up to thread safing newlib that I've provided to some of my colleagues/customers when they've asked is basically the same as in your link. We never got around to it in TrueSTUDIO but I'll make a ticket to the MX team to hopefully have them thread safe by default upon generation of a project with FreeRTOS enabled.

[Dave Nadler · Accepted solution]

@Markus GIRDLAND​ - Its not just thread safety (as if that isn't bad enough).

malloc fails completely in a FreeRTOS task because STM provides an incorrect sbrk function.

There are at least a dozen posts on this forum about problems this has caused (though most don't realize why they're getting crashes, memory corruption, or sprintf float failures).

You're telling us you've been aware of these problems for a year and never bothered to fix them?

Yikes.

STM really needs to get this fixed.

[Bob S]

That is a great summary and description on your web page. I can't believe that strtok() calls malloc(). I had to test that for myself, and sure enough it does. However, I can't find that malloc() call in the newlib source from sourceware.org. Not in the current 3.x version, nor in the 2.5 tag (which *may* be what I am using?????). Have you found any lib source that shows strtok() calling malloc()?

For anyone wanting to see how/where malloc() is getting linked into their code, the linker flag "--trace_symbol=malloc" will list every function that calls malloc to the console.

[Bob S]

Never mind, found it. That darned _REENT_CHECK_MISC macro expands to _REENT_CHECK which can/may call malloc() the first time strtok() is called to allocate part of the re-entry structure. strtok_r() doesn't do that.

[Dave Nadler]

@Bob S​ Thanks, make sure you like the above post ;)

Check _newlib_version.h for version info.

You can see the call sequence into malloc by breakpointing the wrapped malloc (instructions in heap_useNewlib.c).

In newlib source IIRC the malloc is in the macro _REENT_CHECK (in reent.h).

Hope that helps!

Best Regards, Dave

[Dave Nadler]

@Bob S​ wrote: For anyone wanting to see how/where malloc() is getting linked into their code, the linker flag "--trace_symbol=malloc" will list every function that calls malloc to the console.

Careful, that doesn't cover all the cases.

You have to look for malloc_r (called by malloc, and directly by many library functions).

To see clearly why you're getting uses from your code, breakpoint the wrapped malloc_r ;)

[crackwitz]

can I just add... THANK YOU SO MUCH for compiling that article. I ran into this problem, googled the symptoms, dug into where the hardfault happened, googled some more. it seems that most people are faintly aware of the problem and some even know to "mess with" _sbrk, but nobody else presented a proper solution or explained the intricacies.

ST really needs to open-source all of this so people can actually FIX it rather than waiting for support to get around to it.

[JB2500]

Dave Nadler wrote:

> ST really needs to get this fixed.

Indeed they do.

They're too sluggardly for my liking.

The sbrk problem is surely a good test of their attitude and ability.

Anyway, many thanks Dave for your excellent analysis of, and solution to, the problem.

Cheers,

JB.

[Dave Nadler]

I've provided an updated version of the web page and code here:

http://www.nadler.com/embedded/newlibAndFreeRTOS.html

@Markus GIRDLAND​ - Any status update?

Please let your architecture group know they're free to contact me for any clarifications or suggestions,

Thanks,

Best Regards, Dave