2026-03-06 7:02 AM - last edited on 2026-03-06 7:13 AM by Andrew Neil
Using various STM32 MCUs, I have a intermittent bug occuring in malloc() where it returns a nonsensical address for no apparent reason.
After hours of digging I managed to find some some source code for newlib from https://sourceware.org/newlib/
for newlib-4.5.0.20241231 which at least let me step into the internals of malloc to try and find the problem but as thats a slightly different release to the one used by STM32CubeIDE the bug mutated to something less frequent.
My main problem currently is trying to find an issue list \ bug tracker for newlib, so I can see what issues others are having with it. Usually I end up on a site like github and their issue tracker, which is great, but for newlib there seems to be a myraid of git repos and sourceware.org with primitive mailing lists, some being long in the tooth.
It would also have helped if ST Micro indicated exactly which version of newlib they embed into STM32CubeIDE (and\or provided the source code for it too).
Solved! Go to Solution.
2026-03-06 2:07 PM - edited 2026-03-06 2:10 PM
2026-03-06 7:04 AM
There's no chance there's a bug in malloc in newlib that has somehow gone unnoticed.
2026-03-06 8:56 AM
When a malloc() returns a value of 0x000000A0, something ain't working correctly.
Besides I want to know why its failing.
So far I have determined that inside nano_malloc() variable r goes to value 0x9C, (which then eventually becomes 0xA0 on return).
2026-03-06 2:07 PM - edited 2026-03-06 2:10 PM
2026-03-07 1:26 AM
Ahh great, thanks for those github links.
The way I found out about newlib inside STM32CubeIDE was via the linker cmd line \ output... my build used this path to link in libc-nano.a -->
/home/main/.eclipse/com.st.stm32cube.ide.mcu.rcp.product_2.0.0_1934254364_linux_gtk_x86_64/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.14.3.rel1.linux64_1.0.0.202510151430/tools/bin/../lib/gcc/arm-none-eabi/14.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m/nofp/libc_nano.a
From that I determined I needed to use a "thumb/v7e-m" version of libc. So using that info and some digging around the internet I came across newlib-4.5.0.20241231 source from sourceware.org as a first attempt for usable source code.
I see now in your github links that they contain "14.3.rel1" - and my linker path above also has the same, so that matches up.
I just tried using STM32CubeIDE "Installation Details" (in the About Dialog), and it is possible to find some entries relating to "14.3.rel1", but searching for "newlib" displays nothing, so its invisible to a lay user.
Later on I'll see if I can switch over to using the github source instead of the sourceware.org version.