mirror of https://github.com/ARMmbed/mbed-os.git
a6e21a805e
armcc fopen allocated a mutex using the retargeted system-level _mutex_initialize function. Interestingly, malloc also uses this same _mutex_initialization function, which prevents a full solution relying on malloc. The solution previously implemented involved using the rtx mutex pool for the first 8 mutexes, then falling back on malloc. The previous implementation relied on osMutexNew returning an error on out-of-memory. An unrelated change causes osMutexNew to instead assert (except for release mode). This meant if you exceed 8 system- level mutexes in armcc you will hit an assert. Since the filesystem code can call fopen an unlimited number of times, this is a problem. Solution is to keep track of which static mutexes we've allocated, so we know before calling osMutexNew if we need to call malloc. Also _mutex_free never deallocated the malloced mutexes, which would cause fopen to leak memory. |
||
|---|---|---|
| .. | ||
| rtx4 | ||
| rtx5 | ||
| mbed_boot.c | ||
| mbed_rtos1_types.h | ||
| mbed_rtos_storage.h | ||
| mbed_rtx_conf.h | ||
| mbed_rtx_handlers.c | ||
| mbed_rtx_idle.cpp | ||