Heap boundary protection

Christian Mauderer Christian.Mauderer at embedded-brains.de
Fri Sep 11 08:30:51 UTC 2009


i want to suggest a new implementation of the heap boundary protection.
This feature, which seems interesting for debugging purpose, is disabled
since RTEMS 4.6.
I think, that it should be easier to bring it directly into the
heap-control instead of in the malloc functions like in the old
implementation. Therefore the following additional fields in the heap
block  header would be necessary:
  -  one protector field after the "prev_size" field to catch writing
over the end of the allocation area and
  -  one protector field between the "size_and_flag" field and the
"next" pointer to catch writing over the begin of the allocation area.

To initialize and test the fields, there could be the following structure:
  typedef struct {
    void (*at_alloc)(Heap_Block *, void *);
    void (*at_free)(Heap_Block *, void *);
    void (*at_error)(Heap_Block *, void *);
    void *arg;
  } Heap_Boundary_protection;
By default the functions would have the following role:
The at_alloc(..) function initializes the alloc_begin_protector in the
actual block header and the alloc_end_protector in the header of the
next block with an pattern. It  should be called in the
The at_free(..) function should be called in the _Heap_Free function. It
compares the patterns in the protector fields with the one originally
written and calls the at_error(..) function if it is not the same. The
at_error(..) could by default call an internal error.

The structure should be user-overwritable so that the user can replace
the default functions with his own.

The complete code should only be active if RTEMS_DEBUG is set.

The pattern should be chosen so, that it is noticeable if the
size_and_flag is overwritten. Therefore it should not contain any value
which is allowed for this field. This could be achieved by setting at
least the second least significant bit. The rest of the pattern should
be a random pattern. For example the following four word pattern:
With this it should be possible to catch most common failures actually
caught with many slow _Heap_Walk calls, which are enabled with the
RTEMS_DEBUG configuration.

Do you think, that this implementation would be appropriate?

Kind regards,
Christian Mauderer

Christian Mauderer, embedded brains GmbH

Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone   : +49 89 18 90 80 79-1
Fax     : +49 89 18 90 80 79-9
E-Mail  : christian.mauderer at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

More information about the users mailing list