What specifically causes an OS_Error( OS_ERR_INV_TASK)?

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • What specifically causes an OS_Error( OS_ERR_INV_TASK)?

    I've got a problem in my code where embOS is calling OS_Error() indicating that the problem is OS_ERR_INV_TASK. I'm wondering what data item embOS is determining is corrupt that causes it to throw that error so I can narrow down my troubleshooting to the right areas (unfortunately I'm working without a source license to embOS).

    Note that I want to make clear that I understand this isn't an embOS problem - some data structure is being corrupted (probably a TCB). I'm just wondering if there's a particular set of fields in the TCB I should concentrate on, and if the corruption is in the 'current' TCB or can it be any TCB in the task list? This is a problem that has been seen only once so far and not while a debugger was attached. It's proving to be difficult to repro, so as much as possible I want to make sure I'm looking the right things for when it does repro I can have a hope of catching it.
  • Hi,

    several embOS API functions checks if the task, they are working on, is a valid task and not overwritten by other data.

    Every Task control block (TCB) has a structure member ID, which has a default value, when the task is created.
    When the TCB is overwritten by some reason it is very likely that the ID field is also overwritten. embOS detects
    now that the ID field has not longer the default value and calls OS_Error().

    You should check which function calls OS_Error() and check what happens there.
    Are your task stacks big enough?

  • Thanks very much for this infomratino - I think it'll be a big help in debugging this. Unfortuantely, all I have at this point is a log message that says the OS_Error() was called with that particular error code and which task was active at that time. I have no core dump or stack trace, so I don't know what function might have called OS_Error() or what the stack usage was at the time. I can monitor stack use in a repro attempt, but hopefully knowing what part of the TCB is likely to be corrupted will be a help, too.

    So far we've seen this only once, so this is the kind of bug that it really helps to have as much information up front as possible, because you might only get one chance to catch it again...