Task memory usage info
Rob
It looks like the Tornado Toolkit offers this capability, but I don't
know if APIs are accessible from the code itself.
We have some code that overrides the default new handler which will do
a reset once all memory is exhausted. I'd like to obtain some
information as to what tasks are holding all the memory as to narrow
down potential memory leaks and log it before doing a reset.
TIA
Eddie Sanchez
If you store the taskIDs of the tasks you want to inspect then you
should be able to get each Task Control Block, which store information
like the current stack size, max usage, and more...
In development mode, I have written a taskSwitchHook to check the
stack sizes and print a message if they get 70% full.
--Eddie Sanchez
Kiran S
usage of tasks (highest stack usage,lowest stack usage ,margin etc.). When
there is stack overflow, it will show "OVERFLOW" in the margin.
> _______________________________________________
> VxWorks Users Group mailing list
> VxWe...@lbl.gov
> http://www-csg.lbl.gov/vxworks/
>
>
Andy Kaiser
think), called ScopeTools that plug into Tornado and operate via a
target server. One program in that package, MemScope, will do exactly
what you're looking for.
It's true that everything MemScope displays graphically is available
through other methods as raw data, but if you've got the money to buy
the package, I'd recommend it. We use it where I work, and it's quite
useful.
Andy
Rob
> canegard...@yahoo.com (Rob) wrote in message news:<e24435a6.04033...@posting.google.com>...
> > Does VxWorks expose any APIs to allow profiling of task memory usage?
> > It looks like the Tornado Toolkit offers this capability, but I don't
> > know if APIs are accessible from the code itself.
> >
> > We have some code that overrides the default new handler which will do
> > a reset once all memory is exhausted. I'd like to obtain some
> > information as to what tasks are holding all the memory as to narrow
> > down potential memory leaks and log it before doing a reset.
> >
> > TIA
>
> If you store the taskIDs of the tasks you want to inspect
Why do I need to do this. Can't I just use the taskInfo library and
call taskIdListGet()? I was hoping the taskInfo library had something
in it to get the memory usage of each task but can't find anything.
then you
> should be able to get each Task Control Block, which store information
> like the current stack size, max usage, and more...
How do I get each task control block once I have the task ID's. Is
there an API for this? Again I would have expected something like this
in the taskInfo library.
Rob
> > Does VxWorks expose any APIs to allow profiling of task memory usage?
> > It looks like the Tornado Toolkit offers this capability, but I don't
> > know if APIs are accessible from the code itself.
> >
> > We have some code that overrides the default new handler which will do
> > a reset once all memory is exhausted. I'd like to obtain some
> > information as to what tasks are holding all the memory as to narrow
> > down potential memory leaks and log it before doing a reset.
> >
> > TIA
>
> If you store the taskIDs of the tasks you want to inspect then you
> should be able to get each Task Control Block, which store information
> like the current stack size, max usage, and more...
>
the taskLib. But I don't see where in the TCB there is the heap memory
allocated by the task. The definition for WIND_TCB is
struct WIND_TCB
{
enum { NAME_LEN = 32 };
char name[NAME_LEN];
int spare1;
int spare2;
int spare4;
};
What am I missing?
Eddie Sanchez
look in \tornado\target\h\taskLib.h
Also look at http://www.xs4all.nl/~borkhuis/vxworks/vxw_pt5.html#5.9
under Q: How can I detect a stack overflow?
It has working example of taskSwitchHook.
--Eddie Sanchez
John
> OK, I see you can get the task control block by calling taskTcb() in
> the taskLib. But I don't see where in the TCB there is the heap memory
> allocated by the task.
There is no record of the heap space allocated by each task. To do
that you would need to modify the system allocator to track it (and
you'd also have to deal with cases where one task allocated the block
and a different one frees it).
An alternative strategy would be to place an event point on malloc and
free and use that to record the size of the allocation and the address
allocated (you'll need to catch the start & end of the malloc function
probably), and the address being freed. Since event points are
essentially breakpoints, only breakable tasks would be monitored
(leaving the system tasks, and any others you mark as unbreakable in
their task options, as safe from interruption).
Perhaps a simpler solution to this problem would be to look into tools
like MemScope (part of RTI's ScopeTools package). These do a lot of
this for you (and you will get them up and running much faster, so
buying them will probably be cheaper than actually developing and
debugging your own - unless you are just trying to learn and time is
not an issue!).
HTH,
John...
=====
Contribute to the VxWorks Cookbook at: http://books.bluedonkey.org/