views:

601

answers:

3

Hi

I have a VxWorks application running on ARM uC.

First let me summarize the application;

Application consists of a 3rd party stack and a gateway application. We have implemented an operating system abstraction layer to support OS in-dependency.

The underlying stack has its own memory management&control facility which holds memory blocks in a doubly linked list.

For instance ; we don't directly perform malloc/new , free/delege .Instead we call OSA layer's routines and it gets the memory from OS and puts it in a list then returns this memory to application.(routines : XXAlloc , XXFree,XXReAlloc)

And when freeing the memory we again use XXFree.

In fact this block is a struct which has

-magic numbers indication the beginning and end of memory block -size that user requested allocated -size in reality due to alignment issue previous and next pointers -pointer to piece of memory given back to application. link register that shows where in the application xxAlloc is called.

With this block structure stack can check if a block is corrupted or not.

Also we have pthread library which is ported from Linux that we use to -create/terminate threads(currently there are 22 threads) -synchronization objects(events,mutexes..)

There is main task called by taskSpawn and later this task created other threads.

this was a description of application and its VxWorks interface.

The problem is :

one of tasks suddenly gets destroyed by VxWorks giving no information about what's wrong. I also have a jtag debugger and it hits the VxWorks taskDestoy() routine but call stack doesn't give any information neither PC or r14.

I'm suspicious of specific routine in code where huge xxAlloc is done but problem occurs very sporadic giving no clue that I can map it to source code.

I think OS detects and exception and performs its handling silently.

any help would be great

regards

A: 

If your task exits, taskDestroy() is called. If you are suspicious of huge xxAlloc, verify that the allocation code is not calling exit() when memory is exhausted. I've been bitten by this behavior in a third party OSAL before.

bstpierre
HiThere is no exit() at the code.Thnx
tguclu
The other similar possibility is that the task's entry point simply returns. (Or an exit-like function is called... abort()?)I've also seen this sort of behavior in the case of stack corruption or stack overflow.
bstpierre
A: 

Sounds like you are debugging after integration; this can be a hell of a job. I suggest breaking the problem into smaller pieces.

Process

1) you can get more insight by instrumenting the code and/or using VxWorks intrumentation (depending on which version). This allows you to get more visibility in what happens. Be sure to log everything to a file, so you move back in time from the point where the task ends. Instrumentation is a worthwile investment as it will be handy in more occasions. Interesting hooks in VxWorks: Taskhooklib

2) memory allocation/deallocation is very fundamental functionality. It would be my first candidate for thorough (unit) testing in a well-defined multi-thread environment. If you have done this and no errors are found, I'd first start to look why the tas has ended.

other possible causes

A task will also end when the work is done.. so it may be a return caused by a not-so-endless loop. Especially if it is always the same task, this would be my guess.

And some versions of VxWorks have MMU support which must be considered.

Adriaan
+1  A: 

It resolved.

I did an isolated test. Allocated 20MB with malloc and memset with 0x55 and stopped thread of my application.

And I wrote another thread which checks my 20MB if any data else than 0x55 is written.

And quess what!! some other thread which belongs other components in CPU (someone else developed them) write my allocated space.

Thanks 4 your help

tguclu
And now you can accept an answer and remove your question from Unanswered ;)
zxcat