Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix #274, NumOfChildTasks not decremented #485

Merged
merged 1 commit into from
Feb 25, 2020

Conversation

dmknutsen
Copy link
Contributor

Describe the contribution
Fixes #274, NumOfChildTasks not decremented

Testing performed
Steps taken to test the contribution:

  1. Nominal build process.
  2. Ran unit tests.

Expected behavior changes
NumOfChildTasks will now be decremented when a child task is deleted.

System(s) tested on
Oracle VM VirtualBox
OS: ubuntu-19.10
Version: cFE 6.7.3.0; OSAL 5.0.3.0; PSP 1.4.1.0

Contributor Info - All information REQUIRED for consideration of pull request
Dan Knutsen
GSFC/NASA

Copy link
Contributor

@jphickey jphickey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure this is sufficient to cover the issue. There are a few things here:

  • Only covers child tasks that explicitly call CFE_ES_DeleteChildTask(). Does not cover tasks that exit themselves using e.g. CFE_ES_ExitChildTask().
  • It also assumes and does not confirm that CFE_ES_DeleteChildTask() is called by the another task within the same app. But the API description does not say this is a requirement - It just says it deletes a task specified by the task ID. It would be wrong to assume this.

I suggest an entirely different approach here. The issue is that it might not be possible to catch ALL cases of a task exiting so it is very challenging to keep a counter accurate here.

The only place that NumOfChildTasks is actually used is part of the CFE_ES_GetAppInfo() call which is generally only invoked from the QueryOne/QueryAll ground commands. It would be fairly easy to remove the counter from the global table entirely, which thereby solves the problem of keeping it up to date, and simply scan the app table as part of the CFE_ES_GetAppInfoInternal() implementation itself; just loop through the app table and count the number of entries that have their MainTaskId equal to the AppId being queried. Of course this is slower but this is an infrequent call so I would think the complexity avoided by computing the value on-demand is better than optimizing a rarely-called function.

if (Result != CFE_SUCCESS)
{
CFE_ES_SysLogWrite_Unsync("CFE_ES_DeleteChildTask: Error calling CFE_ES_GetAppIDInternal for Task '%d'. RC = 0x%08X\n",(int)TaskId,(unsigned int)Result);
ReturnCode = CFE_ES_ERR_CHILD_TASK_DELETE;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should NOT return an error here. So long as the OS_TaskDelete returned success, that means the task is actually deleted. This is just an error with record-keeping. Fine to write to the syslog to document the inconsistency event, but the return code to the caller should still indicate the task was successfully deleted.

@@ -1224,16 +1225,34 @@ int32 CFE_ES_DeleteChildTask(uint32 OSTaskId)
if ( OSReturnCode == OS_SUCCESS )
{
/*
** Get the AppID of the calling Application
*/
Result = CFE_ES_GetAppIDInternal(&AppId);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that CFE_ES_GetAppIDInternal() returns the AppID of the calling context. So this assumes that this function will only ever invoked by the same App that created the child task in the first place. But this restriction is not documented in the API description of the CFE_ES_DeleteChildTask() function.

If it is the intent to restrict this to the same app that owns the child task, then this should also be verified prior to doing the delete (i.e. make it an error to delete a child task associated with a different app) and note that restriction in the API documentation.

@skliper
Copy link
Contributor

skliper commented Jan 22, 2020

CCB 20200122 - Discussed, preference is to calculate on request and remove the counter.

Copy link
Contributor

@jphickey jphickey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes to the FSW code look OK to me, but recommending a few changes to the UT test case.

Also as part of this I noticed duplicate storage of the tasks names which I noted in #502

CFE_ES_Global.TaskTable[18].RecordUsed = true;
CFE_ES_Global.TaskTable[18].AppId = 15;
CFE_ES_Global.AppTable[15].AppState = CFE_ES_AppState_RUNNING;
CFE_ES_Global.AppTable[15].TaskInfo.MainTaskId = 25;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Test cases that write to specific fixed entries in the table should focus on the lower numbered entries (ideally just 0-4 if possible).

The size of the actual TaskTable is dependent on the OS_MAX_TASKS setting, and generally needs to be at least 5 to run CFE core tasks in the first place, but no guarantee it of anything beyond that.


CFE_ES_GetAppInfo(&AppInfo,CFE_ES_Global.TaskTable[1].AppId);
uint32 NumORegTasksTemp = CFE_ES_Global.RegisteredTasks;
uint32 NumOChildTastTemp1 = AppInfo.NumOfChildTasks;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't the "NumOfChildTasks" here be a predictable/consistent number based on the previous TaskTable config? That is, I think we should know exactly how many child task entries are associated with the AppId because it was just set up earlier in the test sequence. If we do have a specific number which is the correct answer based on an explicitly set config, then we should assert for that specific number.

Also as a general style thing I think we try to avoid instantiating local variables in the middle of the function.

Copy link
Contributor

@jphickey jphickey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a correction to the previous review, mistakenly submitted as "approve" when it should have been "request changes". Just the UT bits noted in the previous review.

Copy link
Contributor

@jphickey jphickey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Still not quite... see comment.

fsw/cfe-core/unit-test/es_UT.c Outdated Show resolved Hide resolved
@skliper skliper changed the title Fixes #274, NumOfChildTasks not decremented Fix #274, NumOfChildTasks not decremented Jan 30, 2020
Copy link
Contributor

@jphickey jphickey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Real close now....

fsw/cfe-core/unit-test/es_UT.c Outdated Show resolved Hide resolved
Copy link
Contributor

@jphickey jphickey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good now!!

No longer keeps a running count of child tasks
@skliper
Copy link
Contributor

skliper commented Feb 3, 2020

Reset soft to master and checked in again.

@astrogeco astrogeco added the CCB:Ready Ready for discussion at the Configuration Control Board (CCB) label Feb 11, 2020
Copy link

@ghost ghost left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the approach of calculating this on the fly when needed.

@astrogeco astrogeco added this to the 6.8.0 milestone Feb 12, 2020
@astrogeco
Copy link
Contributor

CCB 20200212 - Approved

@astrogeco astrogeco added CCB:Approved Indicates code review and approval by community CCB and removed CCB:Ready Ready for discussion at the Configuration Control Board (CCB) labels Feb 13, 2020
@astrogeco astrogeco changed the base branch from master to ic-20200226 February 25, 2020 19:24
@astrogeco astrogeco merged commit dccf3b2 into nasa:ic-20200226 Feb 25, 2020
@astrogeco astrogeco mentioned this pull request Feb 26, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CCB:Approved Indicates code review and approval by community CCB
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ES AppTable.TaskInfo.NumOfChildTasks incremented but never decremented
4 participants