Stack, heap overflow detection in NIOS2/Eclipse

[Altera_Forum]

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

[Altera_Forum]

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]

Looks like the stuff. 

Currently at 9.1 so should do the trick.  Thanks very much for the quick response. Cos

[Altera_Forum]

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]

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]

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]

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]

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.