newlib

[ghostcaesar]

Hi, I saw the article which raised concerns with re-entrant newlib. I am currently using freertos heap_5.c implementation, and would prefer to remain using that.

If my understanding is correct, another solution is to

set #define configUSE_NEWLIB_REENTRANT 1

then add the following wrap functions

void * __wrap_malloc (size_t c)
{
    vTaskSuspendAll();
    return __real_malloc (c);
    xTaskResumeAll();
}

etc

As long as you have a heap area defined in your linker, and a separate freertos heap area, this would also resolve the problem while allowing me to keep using heap_5 with minimal impact?

[DRNadler]

I think you misunderstand the wrap function. Also, IIRC, this approach did not work because newlib requires other malloc-family functions not implemented by heapxx (IIRC this is documented on my web page). Hope that helps, Best Regards, Dave

On 10/7/2020 12:33 AM, Sheng Cao wrote:

Hi, I saw the article which raised concerns with re-entrant newlib. I am currently using freertos heap_5.c implementation, and would prefer to remain using that.

If my understanding is correct, another solution is to

set #define configUSE_NEWLIB_REENTRANT 1

then add the following wrap functions

|void * wrap_malloc (size_t c) { vTaskSuspendAll(); return real_malloc (c); xTaskResumeAll(); } |

etc

As long as you have a heap area defined in your linker, and a separate freertos heap area, this would also resolve the problem while allowing me to keep using heap_5 with minimal impact?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/DRNadler/FreeRTOS_helpers/issues/2, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADBYXZHUETT5DTRTJUVA2ELSJPVR5ANCNFSM4SG35A4Q.

-- Dave Nadler, USA East Coast voice (978) 263-0097, drn@nadler.com, Skype Dave.Nadler1

[ghostcaesar]

I'm not sure if you understood my approach. In my solution, there are 2 seperate heaps.

1. the system heap, defined by .heap the linker file. This is where malloc, free, realloc calls will get memory from.

2) I also have another heap using heap_5, which will be the combination of another section of the on-chip RAM and an external RAM. Calling pvPortMalloc will get an allocation from here.

My solution is to retain the first system heap, used only by newlib internal functions.

However, as you pointed out, malloc is not re-entrant for newlib, by adding

define configUSE_NEWLIB_REENTRANT 1

and wrapping malloc, free, realloc with task suspend, then it should make malloc calls re-entrant.

pvPortMalloc are re-entrant to start with with heap_5 implementaiton.

Can you let me know if there is anything else that I am misunderstanding?

Thanks Sheng

[ApiumJacob]

@ghostcaesar How do you expect xTaskResumeAll() to run in this function?

void * __wrap_malloc (size_t c)
{
    vTaskSuspendAll();
    return __real_malloc (c);
    xTaskResumeAll();
}

Maybe this will work better?

void * __wrap_malloc (size_t c)
{
    vTaskSuspendAll();
    void* p =  __real_malloc (c);
    xTaskResumeAll();
    return p;
}

If you read Dave's article it points out that FreeRTOS does not have a realloc() and that some libraries, that may be called by your FreeRTOS task, may call realloc(). I did find this tread with a pvPortRealloc() implementation but I have not tested it.

We are currently overriding malloc and free (also new and delete) and calling the FreeRTOS pvPortMalloc() and pcPortFree() and but when we added USB to our STM32 everything broke (which led us to @DRNadler).

I might try both paths: Dave's and overridding realloc() using the above pvPortRealloc() and see which works better (though I'm not quite sure yet I can evaluate the correctness of either method other than not seeing our application crash). Time permitting I'll report back my findings.

Jacob

[DRNadler]

@ApiumJacob - Be careful with ST's USB stack. Extremely buggy, drops CDC packets, missing stuff, sometimes locks up if USB devices unplugged and plugged, etc. We've given up on ST for now, products under development shifted to NXP parts where the available drivers are less buggy.

[DRNadler]

Nothing further to do or answer here...