Resource leak in MemPool tests

[jphickey]

Describe the bug
The TestMemPoolCreate function creates 3 memory pools in total - whenever CFE_SUCCESS is returned, this means a pool was instantiated.

See here:

cFE/modules/cfe_testcase/src/es_mempool_test.c

Line 43 in cfadad6

UtAssert_INT32_EQ(CFE_ES_PoolCreateNoSem(&PoolID, Pool, sizeof(Pool)), CFE_SUCCESS);

cFE/modules/cfe_testcase/src/es_mempool_test.c

Line 48 in cfadad6

UtAssert_INT32_EQ(CFE_ES_PoolCreate(&PoolID, Pool, sizeof(Pool)), CFE_SUCCESS);

cFE/modules/cfe_testcase/src/es_mempool_test.c

Line 53 in cfadad6

UtAssert_INT32_EQ(CFE_ES_PoolCreateEx(&PoolID, Pool, sizeof(Pool), 0, NULL, CFE_ES_NO_MUTEX), CFE_SUCCESS);

However, only the last pool ID is deleted here:

cFE/modules/cfe_testcase/src/es_mempool_test.c

Line 58 in cfadad6

UtAssert_INT32_EQ(CFE_ES_PoolDelete(PoolID), CFE_SUCCESS);

The other two pools are left hanging, and are automatically cleaned up by CFE ES at the time the app exits itself, as designed. However, in the case of the pool with an embedded mutex (the one created at line 48) the mutex will be deleted by both CFE ES resource cleanup and task cleanup, due to the fact that the mutex was created by the task.

Note that the ID validation works, and the mutex is only deleted once - task cleanup gets to it first, and when pool cleanup tries to delete it again, the ID is reported as stale and nothing is deleted, but it does issue a warning about it right here:

cFE/modules/es/fsw/src/cfe_es_mempool.c

Line 415 in cfadad6

CFE_ES_WriteToSysLog("%s: Error %d deleting mutex\n", __func__, (int)MutDeleteStatus);

To Reproduce
Execute CFE functional tests, observe an unexpected warning in the syslog when the test completes:

1980-012-14:03:23.85870 CFE_ES_ExitApp: Application CFE_TEST_APP called CFE_ES_ExitApp
1980-012-14:03:24.75802 CFE_ES_PoolDelete: Error -16 deleting mutex
EVS Port1 66/1/CFE_ES 13: Exit Application CFE_TEST_APP Completed.

Expected behavior
Test should delete all the pools it creates, and this clean up warning should not happen

System observed on:
Ubuntu

Additional context
In a way, this could be considered a happy accident, as it verifies that stale ID rejection is occurring, and everything is working as designed. As a result, there is no real harm done by this double delete, aside from the extra warning.

Reporter Info
Joseph Hickey, Vantage Systems, Inc.

[jphickey]

Note - this test has another issue in that it creates 3 pools but passes the same memory block to all 3. This will likely end up corrupting the pool management structures for the first 2.

The test should either make 3 separate memory blocks, or delete the pool before creating the next one (i.e. one at a time).