Christopher Haster 7e45aee8a5 Fixed mutex assert in armcc fopen and related memory leak ... 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.		2017-11-22 16:53:19 -06:00
..
Include	RTX5: uVisor: Extend thread control block with context	2017-11-01 09:25:43 +00:00
RTX	Fixed mutex assert in armcc fopen and related memory leak	2017-11-22 16:53:19 -06:00
Source	CMSIS/RTX: Remove os_tick_gtim.c	2017-11-01 09:25:42 +00:00