Forum Discussion

UnixDev's avatar
UnixDev
Icon for New Contributor rankNew Contributor
3 months ago

eCoS OS throws execption when freeing memory

We have a firmware applicaiton that makes use of eCoS RtoS and NIOSII core. We have a logic that we first allocate memory dynamically and then if required delete the previous allocated memory and allocate bigger one - this step goes on until requirement is met. But we are observing exception from eCos during execution of these steps - in other words say when we ietrate over the above logic for 7th time, while freeing memory that time we get exception but allocation which is done prior to free succeeds:

ExceptionHandler(data = 0x0, exception_number = 0x0, info = 0x017FFF74)
cyg_hal_exception_handler(regs = ???)
_software_exception_handler(asm)
exception
Cyg_Mempool_dlmalloc_Implementation::free(this = 0x0158AD40, mem = ???, unnamed = ???)
Cyg_Mempolt2<Cyg_Mempool_dlmalloc_Implementation>::free(this = 0x0158AD40, p = ???, size = ???)
free(ptr = ???)
npfree(ptr = 0x017136A0)
vf_free_buffer(buffer = 0x017136A0, size = 0x0007E000)
vfwrite_locked(buf = 0x016956B0, size = 0x1, items = 0x0400, vfd = 0x01696F10)
vfwrite(buf = 0x016956B0, size = 0x1, items = 0x0400, vfd = 0x01696F10)
getfile(asm)
WriteFileToFlash(notUsed = 0x0)
ecos_thread_entry(entry = 0x0D)
Cyg_Scheduler_Base::get_current_thread(inline)
Cyg_Thread::self(inline)
Cyg_Thread::exit(inline)
Cyg_HardwareThread::thread_entry(thread = 0x01262448)
end of frame

Can anyone please let me know why exception is thrown at later part of step process execution and what the fix for this issue?

Embedded Applications Layer

5 Replies

  • BoonBengT_Altera's avatar
    BoonBengT_Altera
    Icon for Moderator rankModerator
    1 month ago

    Hi UnixDev ,

     

    Good day, just following up on the previous clarification.

    By any chances did you managed to look into it?

    Hope to hear from you soon.

     

    Best Wishes

    BB

    • BoonBengT_Altera's avatar
      BoonBengT_Altera
      Icon for Moderator rankModerator
      19 days ago

      HI UnixDev 

      Greetings, as we do not receive any further clarification/updates on the matter, hence would assume challenge are overcome. We will continue to monitor this post for the next 5 days. If there are no further inquiries during this period, I will step back and allow the community to assist with any future follow-up questions.

      Thank you for engaging with us!

       

      HI PrakashPrasad,

       

      Good day, as noted issues mention is different and for better issues management and clarity, would suggest to post the error in the new thread.

      Hope that clarify.

      Best Wishes

      BB

    • PrakashPrasad's avatar
      PrakashPrasad
      Icon for New Contributor rankNew Contributor
      1 month ago

      We are facing a peculiar issue – we have a code that dynamically allocates memory (bigger size as per need) and copies data from an old memory location into it. Later we free up that old memory location. We are observing memory fault error when we either copy data or free the old dynamically allocated memory. We observed that issue occurs when memory is allocated at a HEAP higher address – as per our issue 0x7874eee0.

      I am not sure whether it is a linker script issue or not cause malloc for new memory returns success - perhaps that memory regoion overlaps BSS or STATIC or some other memory and hence the issue. But then why malloc is returned as success - where and how do we specify HEAP bounday and make malloc to fail in such a case.

      • Qingrui_H_Intel's avatar
        Qingrui_H_Intel
        Icon for New Contributor rankNew Contributor
        1 month ago

        Hi PrakashPrasad,

        It seems that you met a different issue with the original one, could you upload the error message in your case?

        Best Regards

  • Sparrow_Altera's avatar
    Sparrow_Altera
    Icon for Occasional Contributor rankOccasional Contributor
    2 months ago

    You may have a possible heap corruption based on the stack trace. The fact that the allocation just before this succeeds, but free dies, fits with heap corruption: malloc didn’t happen to touch the damaged area; free did. Heap metadata is corrupted or the pointer/size you’re freeing is not consistent with how it was allocated.

    Things you can check:

    1. Size mismatch between alloc and free: Confirm that the size used for allocation and the size passed into vf_free_buffer() are always identical.
    2. Buffer overrun/underrun before the 7th free: If bytes_to_copy exceeds either the old or new allocation size, you write -> That trashes the allocator’s metadata. dlmalloc stores control info just before/after the user block; once that’s corrupted, the next free() can blow up. Check all memcpy, memmove, memset, and loops that touch this buffer.
    3. Double free or freeing a modified pointer: After vf_free_buffer(), always set the pointer to NULL. Make sure there’s a single owner of this buffer; no multiple modules freeing it.
    4. Using the buffer after freeing: If your “resize until bigger” logic lives in this area, it’s easy to do: Allocate buffer, Use buffer, Decide you need a bigger buffer → allocate new, free old. But something still holds a pointer to the old buffer and writes into it while or after it’s freed. This again corrupts heap metadata, shows up in a later free(). Ensure that all users of the buffer go through a single handle. Whenever you resize, update that handle everywhere before any further writes.
    5. Memory layout / stack overlap: If stack or some other buffer overwrites the heap region around 0x017136A0, dlmalloc will die on free.

    As a sanity check: Temporarily skip resizing logic

    • Change the code to allocate a large enough buffer once, then use it without freeing/resizing in the loop.
    • Keep all the same write/copy logic.

    If the exception disappears:

    • The problem is very likely tied to how you’re managing allocations (size mismatch/double free).

    If the exception still occurs:

    • The bug is almost certainly a pure buffer overrun/underrun in your write logic, independent of malloc/free.