Task stack overflow with c6678

You need to increase your Task's stack.  Basically you are blowing your stack.

Judah

Hi Judah,

Could tell me how to change or set  that value?

I tried changing tskNdkStackTest.stackSize to 0x2800 in cfg file but the error is still there.

/*
** Create the stack Thread Task for our application.
*/
var tskNdkStackTest          =   Task.create("&StackTest");
tskNdkStackTest.stackSize      =     0x2800; //It was 0x1400
tskNdkStackTest.priority    =     0x5;

Here is my *cfg file 6232.omp_config.cfg for reference.

Thanks in advance.

Julian

Julian,

Do you know about the ROV tool?  It can help you determine which Task is overflowing.

Are there multiple Tasks in your system?  You need to increase the stack size for the failing Task.

Judah

Judah,

I tried ROV and the address points to something labeled as dchild.

This is the screenshot:

I am assuming dchild is the task that is conflicting.

Could you tell me where and how can I modify the stack size for that task?

Regards.

Julian

Judah,

here a liitle more info, a view of ROV and it shows in red a value of stackPeak of 4096.

Regards

Julian

Hi,

I also noticed in problems window that there is a warning about bios.xs.

"C:\\ti\\ccsv5\\utils\\bin\\gmake" -k all
'Building file: ../helloWorld.cfg'
'Invoking: XDCtools'
"C:/ti/xdctools_3_23_04_60/xs" --xdcpath="C:/ti/pdk_C6678_1_1_2_5/packages;C:/ti/ndk_2_21_01_38/packages;C:/ti/bios_6_33_06_50/packages;C:/ti/mcsdk_2_01_02_05/demos;C:/ti/ccsv5/ccs_base;" xdc.tools.configuro -o configPkg -t ti.targets.elf.C66 -p ti.platforms.evm6678 -r debug -c "C:/ti/ccsv5/tools/compiler/C6000 Code Generation Tools 7.4.0" "../helloWorld.cfg"
making package.mak (because of package.bld) ...
generating interfaces for package configPkg (because package/package.xdc.inc is older than package.xdc) ...
configuring helloWorld.xe66 from package/cfg/helloWorld_pe66.cfg ...
warning: ti.sysbios.BIOS: "C:/ti/bios_6_33_06_50/packages/ti/sysbios/BIOS.xs", line 352: ti.sysbios.BIOS : BIOS.heapSize and Memory.defaultHeapInstance have both been set.  BIOS.heapSize ignored.  Using Memory.defaultHeapInstance.
cle66 package/cfg/helloWorld_pe66.c ...
'Finished building: ../helloWorld.cfg'

This cause a terminating execution.

Any help will be appreciated.

Julian

Julian,

Yes, looks like the dchild Task is overflowing its stack.  I am not familar with the specifics of your example but obviously this Task is being created either statically (In the *.cfg) or dynamically (at runtime).  You could look at the 'cdoc' documentation on how to change the stack size but in short there's a property called 'stackSize' that is part of the params structure for an Task instance that can be changed when creating the Task.

Now with a stack overflow, its possible that its not really a stack overflow but rather something scribbling to the top of the stack.  BIOS typically initializes the stack with 0xBEBEBEBE and checks the very top of the stack to make sure this value isn't overwritten.  If its overwritten ROV will report what you see, but you should view the stack in a memory window to determine if its really a stack overflow by looking at the stack to see if the values around the top of the stack is also overwritten or still contain 0xBEBEBEBE.

The warning about BIOS.heapSize and Memory.defaultHeapInstance has nothing to do with this stack overflow.  Its really a harmless warning anyways.  Its simply saying the Heap size was changed two ways and which of the two its actually using.

Judah

Judah,

could you tell me how to  see the stack? I tried searching in Memory Browser but

I did not find it and I tried searching in Registers but it is not there also.

Regards

Julian

You have it right there in ROV....looks like the base (top of the stack) starts at 0x8002cc00

Judah

Judah,

If I understand well, ROV present the stack, addresses with labels, so beside the images I uploaded before What I must search in order

to find what´s wrong? because I did not find anything that give me a hint what is going wrong, sorry this my first approach to ROV.

Julian.

Julian,

Load your executable(s) and go main().  Open a memory brower and point it to the stack address in ROV.  You do understand the concept of a stack right?  On the C6000, the stack uses the highest address first and then grows to reach the low address.  Now, BIOS inits the stack with 0xBEBEBEBE by default so you should see a bunch of these 0xBEBEBEBE at the low addresses of the stack.  At some point, the stack is being used and you shoud no longer see the 0xBEBEBEBE.  When the lowest address of the stack has something other than 0xBEBEBEBE, it means that your stack is overflowed because it went beyond the range of the addresses allocated for the stack.

ROV simply tells you the state of your halted program at any given point.  It does not tell you how your program got into that bad state.

What does a stack overflow point to?  Well, assuming this is a true stack overflow, it likely points to your Task having too many function calls with too many local variables.  Local variables are stored on the stack and everytime you call a function it pushes some context onto the stack so when the function returns it has its original calling context.  In this case, increasing the stack size should solve the problem.

The harder case is if this is not a true stack overflow but a corruption problem where the program incorrectly scribbled something to the top of the stack.  In this case, you need to debug where the bad write is happening.

Judah

Judah 

Judah,

I was reviewing the address of dchild and I get this screnshoot

There appears 0xBEBEBEBE as you said, just that I dont know where the stack ends, so I cannot said if this is

correct or not, maybe you could help me. About that, Could you  tell me where to see where is specified the size

of the task stack?

By the way, I was trying removing code that start cause the problem and I get the point where the system fails just adding an empty function(I comment the code) that

returns a struct.

Julian

Julian,

Your screen shot is in the wrong Stack.  The screen shot that you posted is where the dChild Task is created, but this is not where dChild's stack is.

You need to look at address 0x8002CC00 and the stack size is 4096 or 0x1000 so the Stack for dChild should be from 0x8002CC00 to 0x8002DC00.

Judah

Judah,

I get this screenshot for the low address 0x8002CC00 (highlighted):

and this for the high address 0x8002DC00 (highlighted) :

so if I get it, this seems to be a stack overflow, doesn't it? if yes, Is it necessary to change

the task stack for this particular task( dchild)? if so Where can I modify it?

Julian

Julian,

From your screen shots it actually appears that this may not a stack overflow, but that something is corrupting the dchild's stack.

The reason is that the stack starts at 0x8002DC00 and grows to 0x8002CC00 but you see a bunch of 0xBEBEBEBE near 0x8002DC00 which can only means two things:

1.  Some big local array was allocated on the stack and the buffer was not initialized.  In this case, it could be a true stack overflow because the 0xBE are associated with the array and its memory has not been touched. 

2.  The more likely scenario is that not much of the stack was used but the top of the stack at 0x8002CC00 is corrupted.

I think from a previous screen shot of yours, I believe the dchild Task is being created at runtime so you just need to find where its being created!  That's as best I can tell from your screen shots and descriptions.  There's not much more info I can give you at this point.  You will need to do some debugging!

Judah

Just some more questions:

1.  Are you running on multiple cores?

2.  Are you running a single image or multiple images?

Judah

Judah,

Thansk for your comments.

I am trying to debug the program, I think that what appears in

this link http://processors.wiki.ti.com/index.php/DSP_BIOS_Debugging_Tips

is what I need for catch the problem, because the problem appears  not precisely in the

place where I add the function, so is a little difficult to find with a step execution.

So my question is there any debugging tips for sysbios ?, because I tried with the second  method

explained in link above but it is for bios. Or something similar for try.

Thanks.

Julian

Judah

sorry, I had not seen your last post.

Yes, I am running  8 cores.

I am using one core, I have not implemented the multicore schema.

In the run->debug configurations there are 8 cores enabled.

Julian

Since you are running on multicore but using a single image, (This is what I got from your last post) you need to be careful about where you are placing data.  Any data that can be changed should not be put into shared memory (msmc or ddr).  Each core should have its own heap that does not get clobberd by another core.  I could be wrong but it seems like this is what is going on.

Judah

Judah,

I tried to use just one core, so one core and one image is used but 

the result was the same.

In my project I am using about 750kB for arrays, so I suspect the problem

could be related with some memory overwritten.

It would be good to know how much memory is allowed in arrays, as far as

I know the board I am using TMDSEVM6678LE has 512MByte of RAM  so

I suppose it can handle array memory of a few Megabytes without problem.

The point here, as you said,  must be the memory allocation. I am going to try

with guys of multicore if they can help to clarify this doubts and if they can give me

some advice about the error.

Thank you.

Julian

Judah,

I modified the stack size of DaemonNew function that you tell me and it works well¡¡¡.

I changed it from OS_TASKSTKNORM to OS_TASKSTKHIGH.

I am trying my code and it seems doesn´t have any problem until now .

Just I am a little concern about this, it suppose in future the amount of data the project have to

handle is much more, about 80Mbytes I guess this is going to be a problem for certain libraries

in some point like occurred with ndk. Actually I am not quite sure if the array must affect  Daemon

stack size, I mean I must be missing something , because I declare global arrays and the only thing I do is fill them

and processing with my functions that are not so big.

The array is not aligned, or at least I did not configure that.

The ndk is 2_21_01_08.

Thank you very much

Julian

Could you check the stack peak on the dChild Task and let me know what it is using ROV?  I hope it is truly over 4K and if it is then increasing stack size would fix the issue.

If its not over 4K then, something must be corrupting the top of the stack.

Judah

Certainly stackPeak was increased from 4096 to 4132.

Regards.

Julian