osal_core_UT hanging on MCP750/VxWorks

[jphickey]

Describe the bug
When I run osal_core_UT on the MCP750, it seems to run fine until it gets to the OS_TaskCreate test. About 5 tasks into the process of creating OS_MAX_TASKS, output stops, and the test just hangs. Here are the last few lines of output:

[ PASS] 36.004 ut_oscore_task_test.c:138 - OS_TaskCreate(&g_task_ids[3], g_task_names[3], generic_test_task, OSAL_STACKPTR_C(&g_task_stacks[3]), 0, OSAL_PRIORITY_C(UT_TASK_PRIORITY), 0) (-40) == OS_ERR_INVALID_SIZE (-40)
[ PASS] 36.005 ut_oscore_task_test.c:145 - OS_TaskCreate(&g_task_ids[4], g_long_task_name, generic_test_task, OSAL_STACKPTR_C(&g_task_stacks[4]), sizeof(g_task_stacks[4]), OSAL_PRIORITY_C(UT_TASK_PRIORITY), 0) (-13) == OS_ERR_NAME_TOO_LONG (-13)
[ PASS] 36.006 ut_oscore_task_test.c:158 - OS_TaskCreate(&g_task_ids[i], task_name, generic_test_task, OSAL_STACKPTR_C(&g_task_stacks[i]), sizeof(g_task_stacks[i]), OSAL_PRIORITY_C(UT_TASK_PRIORITY), 0) (-14) == OS_ERR_NO_FREE_IDS (-14)
[ INFO] ut_oscore_task_test.c:87:Starting GenericTask: CREATE_TASK0, id: 10001
[ INFO] ut_oscore_task_test.c:87:Starting GenericTask: CREATE_TASK1, id: 10002
[ INFO] ut_oscore_task_test.c:87:Starting GenericTask: CREATE_TASK2, id: 10003
[ INFO] ut_oscore_task_test.c:87:Starting GenericTask: CREATE_TASK3, id: 10004
[ INFO] ut_oscore_task_test.c:87:Starting GenericTask: CREATE_TASK4, id: 10005
[ INFO] ut_oscore_task_test.c:87:Starting GenericTask: CREATE_TASK5,

To Reproduce
Run osal_core_UT on the MCP750 test platform

Expected behavior
Test should pass

System observed on:
MCP750 VxWorks 6.9

Additional context
This test used to pass, so very confusing as to why it seems to be locking up now.

Reporter Info
Joseph Hickey, Vantage Systems, Inc.

[jphickey]

Perplexingly, as a debug test I added an OS_TaskDelay() here (inside the for loop):

osal/src/unit-tests/oscore-test/ut_oscore_task_test.c

Lines 150 to 166 in 64a6b31

	for (i = 0; i <= OS_MAX_TASKS; i++)
	{
	memset(task_name, '\0', sizeof(task_name));
	UT_os_sprintf(task_name, "CREATE_TASK%d", (int)i);
	if (i == OS_MAX_TASKS)
	{
	UT_RETVAL(OS_TaskCreate(&g_task_ids[i], task_name, generic_test_task, OSAL_STACKPTR_C(&g_task_stacks[i]),
	sizeof(g_task_stacks[i]), OSAL_PRIORITY_C(UT_TASK_PRIORITY), 0),
	OS_ERR_NO_FREE_IDS);
	}
	else if (!UT_SETUP(OS_TaskCreate(&g_task_ids[i], task_name, generic_test_task,
	OSAL_STACKPTR_C(&g_task_stacks[i]), sizeof(g_task_stacks[i]),
	OSAL_PRIORITY_C(UT_TASK_PRIORITY), 0)))
	{
	break;
	}
	}

My objective was to see if the test was just getting ahead of the console output... But then the test actually passed.... !!

[jphickey]

Actually, I may have realized what is going on, and it turns out maybe the OS_TaskDelay() isn't that bad...

The test creates all these tasks, waits for a short period, then deletes all the tasks.

Each task calls UtPrintf which takes a lock.

If the parent thread doesn't wait long enough and deletes the task while it is still in the midst of the UtPrintf() call, the lock is never released. This is further evidenced by the fact that the 5th message only gets halfway printed then stops - probably the task was deleted at that time.