• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 2 answers
  • Subscribers 98 subscribers
  • Views 1535 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RTOS/SYSBIOS: Heap track overflow how to detect where exactly there is a buffer overflow

NancyJ
Intellectual 995 points
Part Number: SYSBIOS

Tool/software: TI-RTOS

Hi all,

I'm using CCSv8, SYS/BIOS 6.70, enabled Heap Tracker, to track heap corruption.

While i debug the code, it was hitting the heap corruption

ti.sysbios.heaps.HeapsTrack: line158: assertion failure: A_bufferoverflow: Buffer overflow xdc.runtiime.Error.raise:terminating execution

But I couldn't find out what exactly causing the buffer overflow, increasing the mem doesn't help with the overflow issue.

is there any other way to find where the over flow is caused?

  • 0
    TI__Guru* 96960 points
    Hi Nancy,

    Have you looked in Tools->ROV in CCS? If you look at HeapTrack in ROV, it will show you the buffer that was overflowed, the task that allocated it, the time it was allocated and the size. With that information, you should be able to narrow it down.

    Also note, with ROV, the check is done on allocated blocks. The message you are seeing is done when you attempt to free the block that was overflowed.

    Todd
  • 0 in reply to ToddMullanix
    Intellectual 995 points
    Hi Todd,
    I'm was able to narrow down, but still something is quite not right. the address it mentioned on the overflow i could not track it in my own mem table that i have allocated, but the address is close to the static array i have defined inside that function.
    function __vla_dealloc is called, when i'm actually not calling any mem free.
    so does it clear the static array when it exits that loop?
    static array address is c00c5dc8, the overflow is reported on 0xc00c5dc0
  • 0 in reply to NancyJ
    TI__Guru* 96960 points
    I expect you are looking at ROV after the free of the overflowed buffer occurred. Probably the easiest thing to do is put a breakpoint on the Error policy function (e.g. xdc_runtime_Error_policyMin__E) and run the application. HeapTrack will raise the error and the policy function will be called. You can look at the backtrace in the CCS debug window to see who freed the corrupted buffer and then figure out who overflowed the buffer.

    Todd
  • 0 in reply to ToddMullanix
    Intellectual 995 points
    Thanks for your time, actually the ROV helped me to back trace where the data had a overflow, but i'm quite surprised as to see, how did the static array ended up in heap alloc list. which had the overflow, its good in another way, otherwise i wouldnt have found the bug in my code.
  • 0 in reply to NancyJ
    TI__Guru* 96960 points
    HeapMem has a single buffer. Since HeapMem supports variable size allocations, it maintains a freelist. Initially that free list is the entire buffer. When an allocation occurs, HeapMem finds a free block in that buffer which matches the size request and adjust the free list accordingly. Only addresses within the single buffer should be on the free list. If you are saying there is an address in the free list that is outside the single buffer, then either your application corrupted something or you freed a block that was not allocated from that heap.

    Todd