Mbed-os: Mutex error in armcc debug serial application

[TaniaMirzin]

Description

• Bug
• Major

---

Bug

Target
K64F

Toolchain:
ARM

Toolchain version:
ARMCompiler5.06u3

mbed-os sha:
https://github.com/ARMmbed/mbed-os/#182bbd51bc8d1b6217477c2b5de3f1d0c5e6249f

Expected behavior
Application reads all injected serial data

Actual behavior
error - Mutex 00000000 error -5: System is out of memory during processing of the data

Steps to reproduce
detailed in https://github.com/ARMmbed/factory-configurator-client-example-internal/blob/armcc_serial_restore/restore_mutex_issue.md

[TaniaMirzin]

@sg-
@bulislaw

[0xc0170]

@TaniaMirzin This is related to this https://github.com/ARMmbed/mbed-os/issues/4688https://github.com/ARMmbed/mbed-os/issues/4688 that you are familiar with.

Have you done any investigation to this issue? What is the backtrace for this?

I would assume osMutexNew returns null inside and errors, not returning actually back to _mutex_initialize ? Is that the case or I am not reading the code correctly?

[ciarmcom]

ARM Internal Ref: IOTMORF-1800

[TaniaMirzin]

@0xc0170
Please check this https://github.com/ARMmbed/mbed-os/issues/5664 to reproduce the issue.

[0xc0170]

Please check this #5664 to reproduce the issue.

References this issue, should it be some other issue number?

[0xc0170]

To provide more details to my above answer, @TaniaMirzin please confirm

https://github.com/ARMmbed/mbed-os/blob/master/rtos/TARGET_CORTEX/mbed_boot.c#L458 - this line gets executed, and right after this https://github.com/ARMmbed/mbed-os/blob/master/rtos/TARGET_CORTEX/rtx5/RTX/Source/rtx_mutex.c#L113 that reports this error reported above? This is a debug message, an application continues , just that this reports this to the serial line.

This error msg is correct that RTX does not have enough memory, but we right after we return use heap to allocate.

@bulislaw Can you confirm ? How we can fix this ? One way without changing RTX (as that event error is correct, there is not a memory, a caller needs to handle this, in our case we do, use heap). Any suggestions?

[TaniaMirzin]

@0xc0170 When I increase number of mutex from 8 to more, this message is not appears.
I think it enough for the confirmation?

[bulislaw]

There was recent commit from @geky touching that, maybe something went wrong?

[0xc0170]

There was recent commit from @geky touching that, maybe something went wrong?

Looks like that, the lines above I pointed are exact changes done in https://github.com/ARMmbed/mbed-os/pull/5526.
@geky Can you please review my analysis above

[geky]

Your analysis sounds right, except #5526 changed this so it would switch to malloc allocations once the rtx heap is depleted _without_ calling osMutexNew first. To avoid the above error.

Oh! Could it be someone else is allocating mutexes from the rtx internal heap before the standard library gets a chance to grab them?

[SenRamakri]

@geky and I discussed about this. At present, we don't want to change the EvrRtxMutexError call made from osMutexNew call(in the case of failure to allocate memory for the Mutex object) to fix this. But we agree that we need some way of ensuring that ARMC libs get the mutexes required for its initialization/operation. We currently do this by defining OS_MUTEX_NUM to be 8 in mbed_rtx_config.h. We are contemplating on changing this to statically allocating memory for Mutex objects(compile time in mbed_boot.c) instead of relying on RTX Mutex pool(because some other clients can still steal those objects before us). Please reply to this on what you think of static allocation for mutex objects or if you have other solutions to discuss.

[geky]

What happens when you use a different toolchain? Other toolchains should error where the first internal-heap mutex is allocated, unlike ARMCC, where the error is pushed here.

[SenRamakri]

Assigning this to myself until we find the right owner.

[SenRamakri]

The PR(https://github.com/ARMmbed/mbed-os/pull/5687) with fix has been integrated, closing the issue.