Fixed mutex assert in armcc fopen and related memory leak #5526
Conversation
|
/morph build |
|
@geky jenkins CI fails with a reason |
Build : FAILUREBuild number : 554 |
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.
geky
force-pushed
the
fix-armcc-fopen-mutex-malloc
branch
from
faeefc5
to
7e45aee
Compare
|
It looks like the weak attributes on the mutex functions were broken in a recent update? I brought them back so that this patch works |
|
@geky Thanks for fixing the weak linkage ! |
|
/morph build |
Build : SUCCESSBuild number : 593 Triggering tests/morph test |
Exporter Build : SUCCESSBuild number : 205 |
Test : SUCCESSBuild number : 406 |
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.
cc @c1728p9, @deepikabhavnani, @bulislaw