Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Altera_Forum
Honored Contributor I
1,398 Views

Stack, heap overflow detection in NIOS2/Eclipse

Hello, all. 

 

I need a solid method to track down potential stack, heap corruption. 

 

Looking at this document: n2cpu_nii5v1.pdf 

 

There is a section called "Overlapping Regions" which states: 

BEGIN QUOTE 

"To detect stack/heap overflows, you can define a small region between 

the stack and heap with no access permissions and assign it a higher priority than the 

larger region. Any access attempts to the hole region trigger an exception informing 

system software about the stack/heap overflow." 

END QUOTE 

 

So, seems like a good method. 

Now looking for details how to implement. 

 

Does anybody know of any examples or documentation illustrating/implementing this? 

 

Thank-you, 

Cos
0 Kudos
7 Replies
Altera_Forum
Honored Contributor I
77 Views

I used this a ways back...see here: http://www.altera.com/support/examples/nios2/exm-niosii-mpu.html 

I think it's still relevant. 

 

Cheers, 

 

slacker
Altera_Forum
Honored Contributor I
77 Views

Looks like the stuff. 

Currently at 9.1 so should do the trick. 

 

Thanks very much for the quick response. 

Cos
Altera_Forum
Honored Contributor I
77 Views

Just wondering... 

 

This mpu would not be used in the release code likely and ultimately I feel I have some stack/heap 

corruption going on and really just looking for a method to deal with this which will potentially have me  

adjust the current code so no corruption takes place. Perhaps putting in the mpu is the best way to go 

even if only for debug purposes.  

 

Or are there other ways to track down and verify stack or heap corruption? 

 

Thx, 

Cos
Altera_Forum
Honored Contributor I
77 Views

Memory protection is likely the safest/best thing to do, but I seem to recall that there used to be a simple compile time option to detect stack overflow. Yeah, it's referred to in this oldish document: http://www.altera.com/literature/hb/nios2/edh_ed51003.pdf 

 

Cheers! 

 

Brendan
Altera_Forum
Honored Contributor I
77 Views

Put a pattern in memory at the lowest address you think the stack should use and check it hasn't been overwritten at various places. 

Limit the heap to stop it allocating above that address. 

Or, maybe, arrange the memory map so that the stack is at the bottom of the physical memory area and arrange for accesses below that base addres to fault. 

There is an options somewhere to cause a fault if the nios accesses a non-existant avalon address. 

(It might be in the hidden menu with all the other useful options.) 

 

Or just limit the size of the heap - you might just be allocating too much memory.
Altera_Forum
Honored Contributor I
77 Views

Thanks, all. 

 

Not 100% sure but it seems a complete regen and compile of sopc, fpga, bsp, app with no changes 

may have fixed the issue I was seeing. I cannot reproduce it now. 

 

I always felt I had enough stack/heap which is about 30KB. Code takes up about 160KB. 

I am not doing any dynamic memory alloc so it is pretty much all stack 

and I really don't think I would have burned through so much of that. 

 

I am thinking somehow the bsp or app build files perhaps were not in sync or got 

corrupted. 

 

We'll see. 

 

Best, 

Cos
Altera_Forum
Honored Contributor I
77 Views

The altera startup code allocates data for 'stdout' so that your code can call printf(). 

If you don't need it, it it worth trying to get rid of it from the image. 

The 'small' libc/bsp build might do that, I use my own initialisation code (sets %sp and %gp) and none of the altera library code at all.
Reply