assertion "REENT malloc succeeded" failed

[JLee.32]

After upgrading CubeIDE from 1.3.0 to 1.6.1 and CubeMx from 5.6.1 to ​6.2.1. I got this error:

assertion "REENT malloc succeeded" failed: file "/build/gnu-tools-for-stm32_9-2020-q2-update.20201001-1621/src/newlib/newlib/libc/time/lcltime.c", line 50

MCU: STM32H750

How to reproduce: Send the BLE message from mobile to BLE chip(QN9021). The BLE chip is connected to MCU via UART.

Any advice would be appreciated.

[JLee.32]

@mattias norlander​ 

I found the issue is happend while using new toolchain(gnu-tools-for-stm32_9-2020-q2-update...). If i switch back to the other installed toolchain (2018), it works fine. I saw you solved some toolchain issues, so could you help to check this issue?

[Amel NASRI]

Hi @JLee.32​ ,

Latest STM32CubeIDE version is 1.7.0. Is initially reported issue still faced with this version?

-Amel

[JLee.32]

@Amel NASRI​ 

Yes, the issue is still faced with 1.7.0.

[Amel NASRI]

Hi @JLee.32​ ,

Thanks for your answer. In such case, I let our CubeIDE experts (@Markus GIRDLAND​ & @mattias norlander​ ) investigate the issue.

-Amel

[JLee.32]

Hi @Markus GIRDLAND​  & @mattias norlander​ ,

I found the root cause is that localtime() is used in the task of freertos. localtime() calls malloc() which returns -1 due to _sbrk(). Using localtime_r() is one solution, but I'm wondering if we can overwrite the standard version of malloc? Please see this link. I add the following code at main.c and main.h, but it shows error. How should I do to overwrite the standard version of malloc?

https://www.freertos.org/FreeRTOS_Support_Forum_Archive/October_2009/freertos_malloc_function_in_FreeRTOS_3444349.html

~~~~~

/* Defining malloc/free should overwrite the standard versions provided by the compiler. /

void malloc (size_t size)

{

/* Call the FreeRTOS version of malloc. */

return pvPortMalloc( size );

}

void free (void* ptr)

{

/* Call the FreeRTOS version of free. */

vPortFree( ptr );

}

~~~~~

Regards,

Jimmy

[Markus GIRDLAND]

Hello Jimmy,

If you implement your own malloc it could be called before the application which might not be OK, depending on the application.

There were changes made to the _sbrk() (sysmem.c) in newer versions of STM32CubeIDE and the easiest way could be to generate a new project and copy over the updated version file with the _sbrk() function.

The application might also not be thread safe and you it's likely you would need to thread safe it, which you could do at the same time you update the _sbrk().

Also, it might be a bit unlikely, but it could be as simple as not using newlib nano. Even if that helps I would still recommend using an updated version of the _sbrk() function.