ARM-software / CMSIS-FreeRTOS

FreeRTOS adaptation for CMSIS-RTOS Version 2

Home Page:https://arm-software.github.io/CMSIS-FreeRTOS/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

how can I avoid the crash?

rameble opened this issue · comments

now I run a testcase which cause freertos reboot:

the testcase source code is as below:

1 osStatus_t uwRet;
2 g_cmsisMutexId = osMutexNew(NULL);
3 uwRet = osMutexDelete(g_cmsisMutexId);
4 uwRet = osMutexDelete(g_cmsisMutexId);

when running at 4th line, system will reboot。

Could you please tell me how can I know g_cmsisMutexId is invalid after executiong 3rd line? thanks a lot.

Hi @rameble,

This is a very common "double free" issue. Consider changing such code to

1 | osStatus_t uwRet;
2 | g_cmsisMutexId = osMutexNew(NULL);
3 | uwRet = osMutexDelete(g_cmsisMutexId);
4 | g_cmsisMutexId = 0;
5 | uwRet = osMutexDelete(g_cmsisMutexId);

Clear the mutex id right after deleting it, see line 4. This will cause the second delete to return osErrorParameter instead of trying to double-free the resource.

Cheers,
Jonatan

thanks for your quick reponse.

The testcase belongs to thirdparty test suite. I can not modify the testcase. So I want to konw whether I can check g_cmsisMutexId is invalid after executiong 3rd line. So I can modify the implementation of the osMutexDelete.

To my knowledge FreeRTOS as no provisions to protect from such scenarios. IMHO it would require changes to the RTOS Kernel itself. An alternative implementation is RTX - and it should prevent from this type of problems.

@ReinhardKeil
thanks a lot. what does RTX mean?

Hi @rameble,

RTX5 is the reference implementation for the CMSIS-RTOS2 API, you can find it as part of CMSIS5.
The documentation is at https://arm-software.github.io/CMSIS_5/develop/RTOS2/html/rtx5_impl.html.

As Reinhard pointed out the RTX5 implementation has double-free protection built-in. FreeRTOS seems not.
Where does this test code come from? It looks somewhat invalid to me as it expects double-free protection which I think is not guaranteed by the API.

Be aware of another limitation/difference: The RTX5 implementation implicitly unblocks all waiting threads upon mutex deletion. FreeRTOS explicitly states one must not delete a mutex/semaphore "that has tasks blocked on it"! The CMSIS-RTOS2 API is not specific in this situation.

Cheers,
Jonatan

Hi @JonatanAntoni @ReinhardKeil

It seems that RTX5 is another RTOS or a implementation standard. Can I use it in my FreeRTOS cmsis adaption project?

In addition, does CMSIS standard Committee provide official test suite or another offical documentation that can be as the evidence that the testcase is invalid. Otherwise, I can not request the thirdparty to remove this testcase.

Thanks a lot.

Hi @rameble,

The basic idea behind CMSIS-RTOS2 API is to have the actual implementation to be replaceable. You could try to replace CMSIS-FreeRTOS with RTX5. This should work as long as you didn't access any FreeRTOS features directly.

Regarding an official test suite we are planning to release one, but this has not been done, yet.

I don't expect any official testsuite could give you evidence that the testcase is invalid. The latest official documentation for osMutexDelete does not make any assumptions regarding double-free. But it clearely states

After this call [note: osMutexDelete], the mutex_id is no longer valid and cannot be used.

This could be translated to: "Calling any API function with an invalid mutex_id is undefined behaviour."
Hence, the testcase relys on "undefined behaviour" which I'd consider "invalid". I cannot comment further on a third party testsuite, sorry.

Cheers,
Jonatan

Thanks a lot. Your suggestion is very helpful.

I have no idea on the workload of replacing FreeRTOS with RTX5. Are there any workload on hardware apdation or kernel adaption?

HI @rameble,

The workload depends mainly on two aspects:

  • Development environment you are using. In Keil MDK replacing CMSIS-FreeRTOS with RTX5 is just a view clicks.
  • Coupling of the application with details of the RTOS implementation. This can range from nearly no additional effort to lots of effort.

Sorry for not being more specific. I'd need to know much more details about your project.

Cheers,
Jonatan

Hi @JonatanAntoni ,
thanks for your patient reponse.

Cheer.
Ramble