Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
11 years ago

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

7 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    Looks like the stuff.

    Currently at 9.1 so should do the trick.

    Thanks very much for the quick response.

    Cos
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    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.