[Bug 1672] New: Heap protection

bugzilla-daemon at rtems.org bugzilla-daemon at rtems.org
Thu Aug 12 10:35:19 UTC 2010


           Summary: Heap protection
           Product: RTEMS
           Version: HEAD
          Platform: All
        OS/Version: RTEMS
            Status: NEW
          Severity: enhancement
          Priority: P3
         Component: cpukit
        AssignedTo: joel.sherrill at oarcorp.com
        ReportedBy: sebastian.huber at embedded-brains.de

I have a debug support for the super core heap handler.  It covers boundary
violations, general heap block corruption, double free and usage of freed
memory.  The space overhead is 7 words per heap block.  The time overhead is
minimal for allocations and during free it depends on the allocation size (the
freed memory will be marked with a pattern).  There are also non-deterministic
work loads during free.

It is plugable with handlers for block initialization, checks and errors:

  typedef struct {
    void *handler_data;
    void (*init_block)(Heap_Control *heap, Heap_Block *block);
    bool (*check_block)(Heap_Control *heap, Heap_Block *block);
    void (*block_error)(Heap_Control *heap, Heap_Block *block);
    Heap_Block *first_delayed_free_block;
    Heap_Block *last_delayed_free_block;
    uintptr_t delayed_free_block_count;
  } Heap_Protection;

If enabled, this structure is a part of Heap_Control.  The handler functions
will be called by the general heap code.

In order to check if a heap block (Heap_Block) is valid I added protector

  typedef struct {
    uintptr_t protector [HEAP_PROTECTOR_COUNT];
    Heap_Block *next_delayed_free_block;
    Thread_Control *task;
    void *tag;
  } Heap_Block_protection_begin;

  typedef struct {
    uintptr_t protector [HEAP_PROTECTOR_COUNT];
  } Heap_Block_protection_end;

The task and tag fields are optional.  They are useful for debugging problems
related to usage of freed memory.  The task field points to the task which
allocated the memory.  The tag field should be set by high level allocation
functions to give a hint about the user, e.g. the return address of the
allocation function.

struct Heap_Block {
  uintptr_t prev_size;

    Heap_Block_protection_begin Protection_begin;

  uintptr_t size_and_flag;

    Heap_Block_protection_end Protection_end;

  Heap_Block *next;
  Heap_Block *prev;

Here we have a space and time overhead which may be to much for certain
applications, thus I would not enable this feature by default.  I would enable
it depending on RTEMS_DEBUG.  If you have a heap problem in a production system
you deserve evil consequences.  The heap protection should be an aid during

Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

More information about the bugs mailing list