#1672 closed enhancement (fixed)

Heap protection

Reported by: Sebastian Huber Owned by: Joel Sherrill
Priority: normal Milestone: 4.11
Component: score Version: 4.11
Severity: minor Keywords:
Cc: gedare@… Blocked By:
Blocking:

Description

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
fields:

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;

#ifdef HEAP_PROTECTION

Heap_Block_protection_begin Protection_begin;

#endif

uintptr_t size_and_flag;

#ifdef HEAP_PROTECTION

Heap_Block_protection_end Protection_end;

#endif

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 debugging.

Attachments (2)

heapprot.patch (19.5 KB) - added by Sebastian Huber on 08/12/10 at 09:40:15.
Proposal.
heapprot_v1.patch (21.6 KB) - added by Sebastian Huber on 08/13/10 at 08:15:23.
Proposal.

Download all attachments as: .zip

Change History (6)

Changed on 08/12/10 at 09:40:15 by Sebastian Huber

Attachment: heapprot.patch added

Proposal.

comment:1 Changed on 08/12/10 at 14:22:56 by Gedare Bloom

Cc: giddyup44@… added

Changed on 08/13/10 at 08:15:23 by Sebastian Huber

Attachment: heapprot_v1.patch added

Proposal.

comment:2 Changed on 08/13/10 at 08:15:23 by Sebastian Huber

attachments.isobsolete: 01

comment:3 Changed on 12/03/13 at 14:20:02 by Sebastian Huber

Resolution: fixed
Status: newclosed

Yes, only the heapwalk test fails due to an enabled heap protection, everything else is fixed now.

comment:4 Changed on 11/24/14 at 18:58:28 by Gedare Bloom

Version: HEAD4.11

Replace Version=HEAD with Version=4.11 for the tickets with Milestone >= 4.11

Note: See TracTickets for help on using tickets.