taskSuspend

[Shareef SK]

hi all,

my task is going into SUSPEND state.

Can u give me some situations where a task can get suspended.

thanks in advance
shareef

[PAD]

Hello Shareef,

According to taskStatusString()'s manual: the SUSPEND state means that
the "task is unavailable for execution (but not delayed, or pended).".

A newly created task is initially in the SUSPEND state before it is
activated. Also when the taskSuspend() API or 'ts' shell command are
used on a task it will be in the SUSPEND state.

--
PAD

[Festivus]

A machine exception or other kernel error will usually suspend a task as
well.

--
"I have recently been examining all the known superstitions of the
world, and do not find in our particular
superstition (Christianity) one redeeming feature. They are all alike,
founded upon fables and mythologies."
-- Thomas Jefferson

[PAD]

Hi Festivus,

Actually it appears that this depends on the VxWorks version. In pre-
VxWorks 6.x an exception will put the task in the suspend state. In
vxWorks 6.x it depends on whether the Error Detection & Reporting
(ED&R) feature is configured in or not. If not, you get the same
behavior as with VxWorks 5.x (i.e. the task getting an exception ends
up in the suspend state). However if ED&R is configured in the task
ends up in the stop mode.

Cheers,

--
PAD

[Festivus]

Thanks. I haven't yet moved to 6.x. As anyone using pre-6.x software
knows, the only useful thing you can do with the task once suspended is
to trace back through the call stack to see where things went wrong.

What operationally is the difference between suspended and stopped?

[PAD]

On Nov 16, 8:56 am, Festivus <auto43...@hushmail.com> wrote:
>
> What operationally is the difference between suspended and stopped?

The only difference I can see is that a stopped task cannot be resumed
whereas a suspended task can. Of course in case of an exception
resuming the task will simply trigger the exception again.

--
PAD

[PAD]

Nabendu,

According to the documentation excConnect() will continue the
execution of the task after the handler routine has been called. If
your handler routine has not performed any corrective action (such as
making so that the required memory area becomes available) it is
logical that the task get suspended since it cannot actually continue
its execution in a situation such as the one you described. I fit is
not possible, in the context of your test, to make the memory
available then you'll probably have to use the setjmp() and longjmp()
API, in conjunction to your handler routine, to go back to a known
point of execution after the exception has happened and continue on a
different path of execution from there.

Cheers,

--
PAD

[Shareef SK]

On Nov 16, 5:28 am, PAD <pierre-al...@comcast.net> wrote:
Bonjour ,

Thanks for the info,

I will describe my situation:

In the field when my system (BTS) is running fine after a couple of
days it suddenly resets . When i look into the OFP data, i see that
there is a particular task "tMmetask" which is in suspended state .
My Vx-works kernel is running on 5.4. This behaviour is occuring very
often.

Decoding the stack we observe that the last point of execution was
"memPartFree" routine and then later "taskSuspend" routine was called
before the reset. We observe a message on the console saying "trcStack
aborted: error in top frame".

please help to let me know what has led to this situation and also how
can i avoid these resets.

Thank you,
Shareef

> Hi Festivus,
>
> Actually it appears that this depends on theVxWorksversion. In pre-VxWorks6.x an exception will put the task in the suspend state. InvxWorks6.x it depends on whether the Error Detection & Reporting

> (ED&R) feature is configured in or not. If not, you get the same

> behavior as withVxWorks5.x (i.e. the task getting an exception ends

[Festivus]

Shareef SK wrote:
>
>
> On Nov 16, 5:28 am, PAD <pierre-al...@comcast.net> wrote:
> Bonjour ,
>
> Thanks for the info,
>
> I will describe my situation:
>
> In the field when my system (BTS) is running fine after a couple of
> days it suddenly resets . When i look into the OFP data, i see that
> there is a particular task "tMmetask" which is in suspended state .
> My Vx-works kernel is running on 5.4. This behaviour is occuring very
> often.
>
> Decoding the stack we observe that the last point of execution was
> "memPartFree" routine and then later "taskSuspend" routine was called
> before the reset. We observe a message on the console saying "trcStack
> aborted: error in top frame".
>
> please help to let me know what has led to this situation and also how
> can i avoid these resets.

If you come up with an answer to this question that doesn't
substantially impact run time performance, you'll be a rich man!

It sounds like you have corrupted memory. In my experience, memPartFree
will die as you say when you attempt to free a pointer that does not
actually point to heap allocated memory. Exactly how is of course what
you want to know, but that's not so simple. The lack of a stack trace
indicates that something has overwritten memory it does not own.
Perhaps you have an uninitialized pointer, or you've written past the
end of a string. Maybe you're double deleting a pointer. Perhaps your
stack has been exceeded in one of your tasks and is stomping on memory.
Unless you're using the vxWorks virtual memory add-on, you're in for a
long debug session to uncover precisely what's up.

To answer how to stop these problems in the future is not a vxWorks
question. Your asking a generalized question about program correctness.
The things I do to avoid these problems are many:
1. Don't use the C string library if you can avoid it. Use the
standard C++ string class. I've seen more bugs from char array handling
in C than from any other single source.
2. Don't manage memory by yourself unless you must. Use the standard
library (the STL in particular) to manage variable sized containers of
stuff.
3. Make sure you're initializing all variables before use, especially
pointers.
4. Lint your code and pay attention to the results.
5. Use smart pointers where possible and the "Resource Acquisition is
Initialization" idiom.
6. Don't put large data structures on the stack.

Of course, in a real time environment, you have to sacrifice some of
these niceties some of the time - but always use the safest approach
that still meets your performance needs, and you'll make fewer mistakes.