How to Handle Memory Overflow Issues in Embedded Systems

Follow【Plain Embedded】，Exciting content delivered first

Memory overflow is one of the most common and dangerous issues in embedded system development, which can lead to system crashes, data corruption, and even security vulnerabilities.

This article will delve into the types, hazards, and systematic preventive measures for memory overflow in embedded environments.

Major Types of Memory Overflow

1. Stack Overflow

• Definition: Occurs when the function call depth is too deep or local variables occupy more space than the stack size.
• Typical Scenarios:
• Deep recursive calls
• Large local arrays or structures
• Excessive interrupt nesting

2. Heap Overflow

• Definition: Dynamic memory allocation exceeds available heap space.
• Typical Scenarios:
• Unchecked return values from malloc/calloc/realloc
• Memory leaks leading to gradual depletion of heap space
• Severe memory fragmentation

3. Static Data Area Overflow

• Definition: Global or static variables exceed reserved space.
• Typical Scenarios:
• Out-of-bounds access to large global arrays
• Not considering BSS/DATA segment size limits

4. Memory Corruption

• Definition: Illegal access or modification of adjacent memory areas.
• Typical Scenarios:
• Out-of-bounds access to arrays/pointers
• Using freed memory
• Unprotected shared memory in multitasking

Severe Consequences of Memory Overflow

1. System Crash: The most direct consequence is program failure or hardware anomalies.
2. Data Corruption: Can damage critical data and is difficult to trace.
3. Security Vulnerabilities: Buffer overflow is a common attack vector (CWE-120).
4. Random Failures: Issues may appear intermittently, making them hard to reproduce and debug.
5. Field Maintenance Costs: Fixing memory issues after deployment is extremely costly.

Systematic Preventive Measures

1. Memory Planning Phase

(1) Memory Layout Design

/* Linker script example: Define sizes of each memory area */
MEMORY
{
    FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 256K
    RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 64K
}

/* Define stack and heap sizes */
_stack_size = 4K;
_heap_size = 8K;

(2) Resource Budget Table

Establish memory budgets for each module/task:

2. Coding Practices

(1) Stack Overflow Prevention

// Avoid large local variables
void process_data() 
{
    // Not recommended: large array on stack
    // uint8_t buffer[4096]; 
    
    // Recommended: use static or heap allocation
    static uint8_t buffer[4096];
    // or
    uint8_t* buffer = malloc(4096);
    if(buffer) 
    {
        /* Processing logic */
        free(buffer);
    }
}

// Limit recursion depth
#define MAX_RECURSION_DEPTH 10
void recursive_func(int count) 
{
    if(count >= MAX_RECURSION_DEPTH) 
    {
        return; // Reached depth limit
    }
    recursive_func(count + 1);
}

(2) Heap Overflow Prevention

// Safe memory allocation wrapper
void* safe_malloc(size_t size) 
{
    if(size == 0 || size > HEAP_LIMIT) 
    {
        log_error("Invalid malloc size: %zu", size);
        return NULL;
    }
    
    void* ptr = malloc(size);
    if(!ptr) 
    {
        log_error("malloc failed for size: %zu", size);
        // Trigger memory recovery or safe mode
        emergency_handler();
    }
    return ptr;
}

// Memory allocation statistics
static size_t total_allocated = 0;
void* tracked_malloc(size_t size) 
{
    if(total_allocated + size > HEAP_LIMIT) 
    {
        return NULL;
    }
    void* ptr = malloc(size);
    if(ptr) 
    {
        total_allocated += size;
    }
    return ptr;
}

(3) Safe Access to Arrays/Pointers

// Safe array access macro
#define SAFE_ARRAY_ACCESS(arr, index, size) \
    ((index) < (size) ? &(arr)[(index)] : NULL)

// Usage example
int buffer[100];
int* elem = SAFE_ARRAY_ACCESS(buffer, index, 100);
if(elem) 
{
    *elem = value;
} 
else
{
    handle_error();
}

3. Detection and Protection Mechanisms

(1) Stack Monitoring Techniques

// Stack Canary
#define STACK_CANARY_VALUE 0xDEADBEEF
uint32_t __stack_chk_guard = STACK_CANARY_VALUE;

// Compiler-provided stack protection function
void __stack_chk_fail(void) 
{
    emergency_restart(); // Emergency handling on stack corruption
}

(2) Heap Integrity Checks

// Add sentinel values to memory allocation
typedef struct 
{
    uint32_t head_magic;
    size_t size;
    uint8_t data[];
    uint32_t tail_magic;
} SafeAllocBlock;

#define MAGIC_NUMBER 0xCAFEBABE

void* safe_alloc(size_t size) 
{
    SafeAllocBlock* block = malloc(sizeof(SafeAllocBlock) + size + sizeof(uint32_t));
    if(block)
    {
        block->head_magic = MAGIC_NUMBER;
        block->size = size;
        *(uint32_t*)(block->data + size) = MAGIC_NUMBER;
        return block->data;
    }
    return NULL;
}

int validate_memory(void* ptr) 
{
    SafeAllocBlock* block = (SafeAllocBlock*)((uint8_t*)ptr - offsetof(SafeAllocBlock, data));
    return (block->head_magic == MAGIC_NUMBER) && \
           (*(uint32_t*)(block->data + block->size) == MAGIC_NUMBER);
}

(3) MPU/MMU Protection

; Use ARM MPU to set memory protection regions
; Set read-only code area
MPU->RBAR = FLASH_BASE | REGION_ENABLE | 0x00;
MPU->RASR = STRONGLY_ORDERED | READ_ONLY | SIZE_256KB;

; Set stack protection area (bottom 1KB as red zone)
MPU->RBAR = (STACK_BASE - 1024) | REGION_ENABLE | 0x01;
MPU->RASR = NORMAL_MEMORY | NO_ACCESS | SIZE_1KB;

4. Debugging and Analysis Tools

1. Static Analysis Tools:

• Coverity: Detects potential memory overflow vulnerabilities
• Klocwork: Identifies security issues like array out-of-bounds
• Cppcheck: Simple static checks

# Enable AddressSanitizer at compile time
gcc -fsanitize=address -fno-omit-frame-pointer -g test.c

• Valgrind (Memcheck): Memory debugging in Linux environment
• AddressSanitizer (GCC/Clang): Real-time memory error detection

// Stack usage monitoring thread
void stack_monitor_thread() 
{
    extern uint8_t _estack, _min_stack;
    while(1) 
    {
        uint8_t* p = &_min_stack;
        while(p < &_estack && *p == STACK_FILL_PATTERN) 
        {
            p++;
        }
        uint32_t used = &_estack - p;
        if(used > STACK_WARNING_THRESHOLD) 
        {
            alert_stack_overflow();
        }
        osDelay(1000);
    }
}

// Implement memory status query command
void handle_meminfo_cmd() 
{
    printf("Heap usage: %zu/%zu bytes\n", 
           get_used_heap(), 
           get_total_heap());
    printf("Stack usage:\n");
    print_all_task_stacks();
}

Testing and Validation Strategies

1. Boundary Testing:

• Intentionally allocate maximum available memory
• Test maximum recursion depth
• Input overly long data to test buffer

# Automated memory stress testing script example
def test_memory_limits():
    for i in range(1, 10000):
        # Continuously allocate and free memory of different sizes
        ptr = allocate_memory(random_size())
        if not ptr:
            verify_graceful_failure()
        write_pattern(ptr)
        verify_pattern(ptr)
        free_memory(ptr)

• 72-hour continuous operation test
• Random memory allocation pattern test
• Combined with power cycling tests

• Simulate memory allocation failures
• Intentionally create stack overflows
• Deliberately corrupt memory patterns

Post-Deployment Protective Measures

1. Health Monitoring:

   void system_health_monitor() 
   {
       if(detect_memory_anomaly()) 
       {
           save_debug_info();
           safe_reboot();
       }
   }
   

2. Crash Collection:

• Implement crash information Flash storage
• Include PC pointer, stack trace, memory state
• Automatically transmit diagnostic data after power on

• Multi-stage watchdog design
• Critical data dual backup
• Emergency mode memory protection

Practical Summary

1. Resource-Constrained Systems:

• Prioritize static allocation
• Avoid dynamic memory allocation
• Carefully design data structures

• Implement memory pool management
• Set allocation size limits
• Monitor each allocation and release

• Treat all external inputs as untrusted
• Add boundary check assertions
• Implement safe memory operation wrappers

• Establish strict memory usage guidelines
• Code reviews focus on memory operations
• Regular memory safety training

By implementing systematic preventive measures and strict memory management discipline, the risk of memory overflow in embedded systems can be significantly reduced, enhancing system stability and reliability.

Remember, in embedded systems, the cost of preventing memory issues is far lower than the costs of debugging and field maintenance later.

– EOF –

Follow 【PlainEmbedded】 for easy learning of embedded systems.

If you find this article useful, please click “Share“, “Like“, or “View“!