Dangling Pointer !

Daram,

I can't possibly reach all conclusions without looking at the code and the debugging process, therefore I can only make some comments. 

At first, if this issue always happens at the same location in your code (i.e., not random) it becomes easier to debug. In this case, I would open the Disassembly view to perform an assembly step-by-step debugging and carefully inspect the behavior of the registers.

A bit more specific to this issue, the symptoms you describe are very indicative of either a corrupt stack, which would cause the program to jump to an invalid location and thus potentially causing the DSP core to halt, or an invalid write to a configuration register, which would misconfigure the PLL, external RAM, or other critical component of the system.

The causes for this corruption of a pointer can have many sources, ranging from insufficiently sized stack or heap to misconfigured peripherals or DMA - these could overwrite the sections of the code or data inadvertently (although the peripherals or DMA would happen at random locations in your code). One interesting example of heap allocation problems is shown at this discussion.

Hopefully these suggestions may help you get additional details about the running system.

Regards,

Rafael

At first, if this issue always happens at the same location in your code (i.e., not random) it becomes easier to debug. In this case, I would open the Disassembly view to perform an assembly step-by-step debugging and carefully inspect the behavior of the registers.

yes this is happening with that particular position itself,i have tried to look for other function calls it doesn't happen with them,more over i tried to increase the stack and heap memory sizes by 10's of  Kilo Bytes but this doesn't change the situation of that pointer dangling,which points to a unknown location and results in error to retrive

even if i try to look in to dis-assembly window what can i look in to exactly to understand the situation,is there any way to check out my current stack size ? 

A bit more specific to this issue, the symptoms you describe are very indicative of either a corrupt stack, which would cause the program to jump to an invalid location and thus potentially causing the DSP core to halt, or an invalid write to a configuration register, which would misconfigure the PLL, external RAM, or other critical component of the system.

these any way did not happened at all 

here below i have put the linkerfile 

-stack 0x6000 /*Primary Stack Size 24KBytes*/
-sysstack 0x2000 /*Secondary Stack Size 8KBytes*/
-heap 0x9000 /*Run time Heap memory 36KBytes*/
-c /* Use C linking conventions: auto-init vars at runtime */
-u _Reset /* Force load of reset interrupt handler */
MEMORY
{
/*Unified Program and Data Space*/
PAGE 0:
MMRS (RWIX): origin = 0x000000, length = 0x0000C0 /*Memory Mapped Register - Reserved Memory*/
DARAM0 (RWIX): origin = 0x0000C0, length = 0X00FF40 /*64KBytes-MMRS*/
SARAM0 (RWIX): origin = 0x010000, length = 0x010000 /* 64KB */
SARAM1 (RWIX): origin = 0x020000, length = 0x020000 /* 128KB */
SARAM2 (RWIX): origin = 0x040000, length = 0x00FE00 /* 64KB */
VECS (RWIX): origin = 0x04FE00, length = 0x000200 /* 512B */
PDROM (RIX): origin = 0xFE0000, length = 0x010000 /* 64KB */
PAGE 2: /* -------- 64K-word I/O Address Space -------- */
IOPORT (RWI) : origin = 0x000000, length = 0x020000
}
SECTIONS
{
.text: > SARAM1 /*CODE*/

/* Both stacks must be on same physical memory page */
.stack > DARAM0 /* Primary system stack */
.sysstack > DARAM0 /* Secondary system stack */

.data > SARAM2 /* Initialized vars */
.bss >> SARAM1|SARAM2 /* Global & static vars */
.const >> SARAM1|SARAM2 /* Constant data */
.sysmem >> SARAM1|SARAM2 /* Dynamic memory (malloc) */
.switch >> SARAM1|SARAM2 /* Switch statement tables */
.cinit > SARAM2 /* Auto-initialization tables */
.pinit > SARAM2 /* Initialization fn tables */
.cio > SARAM2 /* C I/O buffers */
.args > SARAM2 /* Arguments to main() */
.vectors: > VECS /*Interrrupt Vectors */
.bootmem: > DARAM0

.myheap: > SARAM0

.ioport > IOPORT PAGE 2 /* Global & static ioport vars */
}

in the above file the .myheap is different from heap,when i am saying -heap <size> which memory location will be allocated for heap ?

kindly note that i am not at all using any sort of malloc in my code i am using a custom malloc which will allocate the memory from .myheap ! so from this its clear that i am not facing this problem because of heap size ? ! but why this not resolved even if the stack size is greatly increased ?

to explain the problem more briefly when going in to that particular function the 'st' address is  0x0000a134

respective figure:

while exiting it that should not change but it has changed to --0x0000a554

respective figure 

by observing the above screenshots its evident that the controller failed to transfer same pointer values in to called parameters so eventually the de-referencing is done to some other place creating a havoc 

finally as a last try i tried to comment that function call which avoid the dangling,from this its clear that the function calls further making these problems i think ,must be problem with stack or some other thing

so from this i understood that the stack holds the return addresses,so i have improved the stack size to 64K then also the problem is not solved then i tried to increase it further then the linker throws me an error saying stack and sysstack should lie in a same 64K page !!!

i am using a large memory model with level 2 optimization,some where i have read the stack and systack criteria is for small memory model only,is that true? if true why am i getting this kind of error

as you have suggested a link on heap ,i tried to improve the heap to 90K even then also the problem did not resolve i dont think that single function is causing such a huge overlap of memories 

i strongly believe the problem lies with stack not heap because heap is concerned with dynamic memory allocations,where as stack is effected by this kind of excessive function calls,return addresses,etc ..

God help me !  :)

Hi,

DARAM said:

even if i try to look in to dis-assembly window what can i look in to exactly to understand the situation,is there any way to check out my current stack size ? 

As I mentioned before, the disassembly allows you to inspect in detail the instructions and the register values (including the stack pointer) when the function preprocess_analysis() is about to return. If any suspicious code (a MOV operation that overwrites an invalid location, for example) or any invalid values are being passed to certain registers, you can tell precisely where this is happening.

There is no functionality to check the remaining stack or heap available, but this thread points to some useful documents that can help you.

DARAM said:

in the above file the .myheap is different from heap,when i am saying -heap <size> which memory location will be allocated for heap ?

kindly note that i am not at all using any sort of malloc in my code i am using a custom malloc which will allocate the memory from .myheap ! so from this its clear that i am not facing this problem because of heap size ? ! but why this not resolved even if the stack size is greatly increased ?

The -heap linker option stores the heap in the .sysmem memory section. However, since you are using your own allocator, this section will not be used.

I will address the rest of the topics at a later post.

Regards,

Rafael

-stack		0xF000		 /*Primary 	 Stack Size 50KBytes*/
-sysstack	0x0E00		 /*Secondary Stack Size	10KBytes*/
-heap		0x6000		 /*Run time Heap memory	24KBytes*/
-c                	     /* Use C linking conventions: auto-init vars at runtime */
-u _Reset           	 /* Force load of reset interrupt handler                */
MEMORY
{
	/*Unified Program and Data Space*/
	PAGE 0:
			MMRS    (RWIX) : origin = 0x000000, length = 0x0000C0  /*MMR-192 Bytes */
			DARAM0  (RWIX) : origin = 0x0000C0, length = 0X00FF40  /*64KBytes-MMRS*/	/*heap and tables*/

			SARAM0  (RWIX) : origin = 0x010000, length = 0x00A000  /*  40KB */			/*my heap*/
			SARAM1  (RWIX) : origin = 0x01A000, length = 0x026000  /* 152KB */			/*code */
			SARAM2  (RWIX) : origin = 0x040000, length = 0x00FE00  /*  63KB */			/*stack*/
			VECS    (RWIX) : origin = 0x04FE00, length = 0x000200  /*  512B */			/*IVT*/
			/*End of SARAM*/
			PDROM   (RIX)  : origin = 0xFE0000, length = 0x010000  /*  64KB */
	PAGE 2:  /* -------- 64K-word I/O Address Space -------- */
			IOPORT (RWI) : origin = 0x000000, length = 0x020000
}
SECTIONS
{
   .text:	 >	SARAM1  				   /*CODE*/

    /* Both stacks must be on same physical memory page             */
   .stack    >  SARAM2		               /* Primary system stack        */
   .sysstack >  SARAM2 		               /* Secondary system stack      */

   .data     >	SARAM0 		 			   /* Initialized vars            */
   .bss      >	DARAM0 		 	   /* Global & static vars        */
   .const    >	DARAM0 		 	   /* Constant data               */
   .sysmem   >	DARAM0 				 	   /* Dynamic memory (malloc)     */
   .switch   >  DARAM0              /* Switch statement tables     */
   .cinit    >  DARAM0               	   /* Auto-initialization tables  */
   .pinit    >  SARAM0               	   /* Initialization fn tables    */
   .cio      >  SARAM0              	   /* C I/O buffers               */
   .args     >  SARAM0              	   /* Arguments to main()         */
   .vectors: >	 VECS		  		 	   /*Interrrupt Vectors           */
   .bootmem: >	 DARAM0

   .myheap:  > 	 SARAM0

   .ioport   >  IOPORT PAGE 2         /* Global & static ioport vars */
}

This is the latest linker file,while my stack lies in range of 0x040000 to 0x04fc00 as size of 63KB(isn't this huge)

after regular debugging i have found 3 problems:

Problem1:

now when i see the SP using debugger the value is  

0x0277FD(at main) 

SP: 0x027777(into preprocess_analysis() )

SSP: 0x027EEE

why so ? isn't it should be in my SARAM2 region  

and also more importantly i was saying my 

#pragma DATA_SECTION(spxHeap, ".myheap");
static char spxHeap[8500+8500];

Problem 2:

but when i see the spxHeap adress its exactly at datasection:0x00008000  but this been clearly mentioned in linker file spxHeap should be placed in SARAM0 but why still it is present in datasection of DARAM0

any thing wrong 

Problem 3:

 this is quite peculiar while going in to function,the function arguments are present with the XAR registers

so after returning the XAR register changed further which changed the dereference value

what is this XAR registers why not my arguments are not auto type instead they are of register type in the above case whose value is changing regularly

when i tried using a global variable instead of a local variable the problem did not appear every time 

Hi,

Sorry for the delay. I have been juggling a few priorities these last days.

Regarding to your questions:

Problem 1. Keep in mind the SP will point to the return addresses of the functions being called throughout the code execution, therefore to me it seems it is correctly pointing to addresses at the SARAM1 memory space - where your code lies.

Problem 2: You are correct in saying that spxHeap should be in the SARAM0 - do you have a linker .map file that you could share? Despite having this file available, unless all your variables are being allocated to this heap, I don't think this would matter much, but it may expose some other differences.

Problem 3: Variables passed as parameters to functions will always be pushed into the stack - thus, you can quickly exhaust your stack if you are not careful with this. The solution is to use pointers as parameters and pass the address of variables, thus avoiding any de-referencing issues (sorry, I don't have your code, therefore I am not sure if you are already doing this or something similar). I am not be explaining this perfectly, but there are some threads that talk about that in a much better fashion: check one here and another here.

Given that you are obtaining better results when declaring your variable as a global (thus being entirely allocated in the memory section .bss, unless specified differently using the DATA_SECTION pragma) indicates to me that either the struct de-referencing is going through the issues mentioned before or the variable allocation is overwriting adjacent memory segments - given that .myheap is adjacent to .text, that could well be a possibility. You could try to put myheap somewhere else in memory with no adjacent memory sections and see if the code becomes stable - this will help diagnose any memory overruns.

Unfortunately I don't have much more ideas on what may be happening in your case, as the code itself is working up to a certain point and it is difficult to make a precise assessment from my stand point.

Hope this helps,

Rafael

desouza said:

Problem 1. Keep in mind the SP will point to the return addresses of the functions being called throughout the code execution, therefore to me it seems it is correctly pointing to addresses at the SARAM1 memory space - where your code lies.