← C

Memory Internals & Debugging

← Memory Internals & Debugging

Select a question from the sidebar

12 questions in this topic

Question 1 / 12

What is virtual memory and how do pages, page tables, and the TLB work?

Virtual memory gives each process the illusion of a large, contiguous address space, even though physical RAM is finite and shared.

Pages: Virtual memory is divided into fixed-size blocks called pages (typically 4KB on x86). Physical memory is divided into page frames of the same size. The OS maps virtual pages to physical frames.

Page table: A per-process data structure that maps virtual page numbers to physical frame numbers. On 64-bit systems, page tables are multi-level (4-level on x86_64) to avoid storing entries for unmapped regions.

Each page table entry (PTE) contains:

Physical frame number
Present/valid bit (is the page in RAM?)
Read/Write/Execute permission bits
Dirty bit (has the page been written to?)
Accessed bit (has it been read?)

TLB (Translation Lookaside Buffer): A small, fast hardware cache of recent page table lookups. Without TLB, every memory access would require 4 page table lookups (on x86_64). TLB hit rate is typically >99% due to locality of reference.

Page fault: When a virtual page is not in RAM (present bit = 0), the MMU raises a page fault. The OS loads the page from disk (swap) into RAM, updates the page table, and retransmits the instruction. This is transparent to the process.

Benefits: Process isolation (each process has its own address space), memory overcommit (more virtual memory than physical RAM), demand paging (load pages only when accessed), shared libraries (same physical page mapped into multiple processes).

Pseudo Code

Virtual address -> MMU:
1. Split address: [VPN (virtual page number)] [offset]
2. Check TLB for VPN:
   - TLB hit: get physical frame number instantly
   - TLB miss: walk the page table (4 levels on x86_64)
3. If PTE present bit = 0: page fault
   - OS loads page from disk to RAM
   - Updates PTE and TLB
4. Physical address = [frame number][offset]

Code

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int main(void) {
    /* Each process sees its own virtual address space */
    int x = 42;
    printf("Virtual address of x: %p\n", (void *)&x);
    /* Same virtual address in different processes
       maps to different physical frames */

    /* Page size is typically 4096 bytes */
    long page_size = sysconf(_SC_PAGESIZE);
    printf("Page size: %ld bytes\n", page_size); /* 4096 */

    /* Total physical pages */
    long phys_pages = sysconf(_SC_PHYS_PAGES);
    printf("Physical memory: %ld MB\n",
           (phys_pages * page_size) / (1024 * 1024));

    /* Allocate memory -- pages are NOT allocated until accessed */
    /* (demand paging) */
    size_t size = 100 * 1024 * 1024; /* 100 MB */
    char *p = malloc(size);
    if (!p) { perror("malloc"); return 1; }

    /* At this point, no physical pages are allocated.
       Only virtual address space is reserved. */

    /* Touching a page triggers a page fault,
       which allocates a physical frame */
    p[0] = 'A';              /* page fault -> allocate 1 page */
    p[page_size] = 'B';      /* page fault -> allocate another page */
    p[2 * page_size] = 'C';  /* page fault -> allocate another page */

    /* Only 3 physical pages used, not 100MB worth */

    free(p);
    return 0;
}

Virtual address of x: 0x<address>
Page size: 4096 bytes
Physical memory: <N> MB
(Addresses and memory size vary per system)

Key Points

•Virtual memory maps virtual pages to physical frames via page tables
•Pages are typically 4KB; x86_64 uses 4-level page tables
•TLB caches recent translations for fast address lookup (>99% hit rate)
•Page fault occurs when a page is not in RAM -- OS loads it transparently
•Demand paging: physical memory is not allocated until a page is first accessed

Gotchas

•malloc does not allocate physical memory -- only virtual address space is reserved until first access
•TLB is per-CPU and flushed on context switch (or per-ASID on modern CPUs) -- frequent switches hurt performance
•Huge pages (2MB/1GB) reduce TLB misses for large allocations but increase internal fragmentation
•Virtual address space is much larger than physical RAM -- processes can map more than available memory

Virtual memory maps virtual pages (4KB) to physical frames via page tables. The TLB caches recent translations. Page faults load missing pages from disk. Each process has its own isolated virtual address space.

•Page table maps virtual pages to physical frames; TLB caches this
•Demand paging: physical RAM allocated only on first access

#include <stdio.h>
#include <unistd.h>

int main(void) {
    printf("Page size: %ld\n", sysconf(_SC_PAGESIZE)); /* 4096 */
    int x = 42;
    printf("Virtual addr: %p\n", (void *)&x);
    /* Same virtual addr in 2 processes -> different physical pages */
    return 0;
}

Page size: 4096
Virtual addr: 0x<address>
(Address varies per run due to ASLR)

malloc reserves virtual space only -- physical pages are allocated on first touch (page fault)

Question 2 / 12

What is the process memory layout (text, data, BSS, heap, and stack segments)?

A process's virtual address space is divided into well-defined segments:

From low addresses to high (typical layout):

Text segment (code): Contains the compiled machine instructions. Read-only and executable. Shared between processes running the same program.
Data segment (initialized data): Global and static variables that have explicit initializers (e.g., int x = 5;). Read-write.
BSS segment (Block Started by Symbol): Global and static variables that are uninitialized or zero-initialized (e.g., static int count;). Takes no space in the executable file -- the OS zero-fills it at load time.
Heap: Grows upward (toward higher addresses). Managed by malloc()/free(). The brk/sbrk system calls (or mmap) expand the heap.
Memory-mapped region: Between heap and stack. Used for shared libraries, mmap() files, and large malloc() allocations.
Stack: Grows downward (toward lower addresses). Contains function call frames: local variables, return addresses, saved registers. Each thread has its own stack.

Between heap and stack is a large unmapped region. Growing into it (stack overflow or heap exhaustion) causes a segmentation fault.

On Linux, /proc/[pid]/maps shows the exact memory layout of a running process.

Pseudo Code

High addresses:
  [Stack]        <- grows downward
  [  ...  ]      <- unmapped gap
  [mmap region]  <- shared libs, mmap files
  [  ...  ]      <- unmapped gap
  [Heap]         <- grows upward (brk/sbrk)
  [BSS]          <- uninitialized globals (zeroed)
  [Data]         <- initialized globals
  [Text]         <- code (read-only, executable)
Low addresses:
  [NULL page]    <- unmapped (catches NULL pointer dereference)

Code

#include <stdio.h>
#include <stdlib.h>

/* Text segment: code (read-only) */

/* Data segment: initialized globals */
int global_init = 42;
static int static_init = 100;

/* BSS segment: uninitialized globals (zeroed) */
int global_uninit;
static int static_uninit;

int main(void) {
    /* Stack: local variables */
    int local_var = 10;

    /* Heap: dynamically allocated */
    int *heap_var = malloc(sizeof(int));
    *heap_var = 20;

    printf("--- Process Memory Layout ---\n");
    printf("Text  (code):  %p (main function)\n", (void *)main);
    printf("Data  (init):  %p (global_init=%d)\n",
           (void *)&global_init, global_init);
    printf("BSS   (zero):  %p (global_uninit=%d)\n",
           (void *)&global_uninit, global_uninit);
    printf("Heap  (malloc): %p (*heap_var=%d)\n",
           (void *)heap_var, *heap_var);
    printf("Stack (local):  %p (local_var=%d)\n",
           (void *)&local_var, local_var);

    /* Verify ordering: text < data < bss < heap < ... < stack */
    printf("\nAddresses increase: text < data < bss < heap\n");
    printf("Stack is at a much higher address\n");

    free(heap_var);
    return 0;
}

--- Process Memory Layout ---
Text  (code):  0x<address> (main function)
Data  (init):  0x<address> (global_init=42)
BSS   (zero):  0x<address> (global_uninit=0)
Heap  (malloc): 0x<address> (*heap_var=20)
Stack (local):  0x<address> (local_var=10)

Addresses increase: text < data < bss < heap
Stack is at a much higher address
(Addresses vary; ASLR randomizes positions)

Key Points

•Text = code (read-only), Data = initialized globals, BSS = zero-initialized globals
•Heap grows upward from low addresses; stack grows downward from high addresses
•BSS takes no space in the executable -- OS zeroes it at load time
•Each thread has its own stack but shares the same heap
•/proc/[pid]/maps shows the exact layout on Linux

Gotchas

•The exact layout varies by OS and ASLR (Address Space Layout Randomization) randomizes segment positions
•BSS variables are guaranteed to be zero at program start -- C standard requires it
•Stack size is limited (typically 8MB on Linux) -- large local arrays can overflow it
•String literals are in the text segment (read-only) even though they look like data

Low to high: Text (code, read-only) -> Data (initialized globals) -> BSS (zeroed globals) -> Heap (grows up, malloc) -> ... -> Stack (grows down, local vars).

•Text < Data < BSS < Heap ... Stack (high to low for stack)
•BSS is zeroed at load time and takes no space in the binary

int global = 42;          /* Data segment */
static int uninit;        /* BSS segment (zeroed) */

int main(void) {
    int local = 10;       /* Stack */
    int *p = malloc(4);   /* Heap */
    /* main() code is in Text segment */
    free(p);
    return 0;
}

ASLR randomizes the base addresses of segments for security

Question 3 / 12

How does mmap() work for memory-mapped files and anonymous mappings?

mmap() maps files or devices into the process's virtual address space, or creates anonymous (non-file-backed) mappings.

Signature:

void *mmap(void *addr, size_t length, int prot, int flags,
           int fd, off_t offset);

Parameters:

addr -- Suggested address (usually NULL to let the kernel choose).
length -- Size of the mapping.
prot -- Protection: PROT_READ, PROT_WRITE, PROT_EXEC, PROT_NONE.
flags -- MAP_SHARED (changes visible to other processes and written to file) or MAP_PRIVATE (copy-on-write, changes are private).
fd -- File descriptor (or -1 for anonymous mappings).
offset -- Offset in the file (must be page-aligned).

File-backed mapping: Maps a file into memory. Reading/writing the mapped region reads/writes the file directly. The kernel handles page faults and disk I/O transparently. Much faster than read()/write() for random access patterns.

Anonymous mapping (MAP_ANONYMOUS): Creates a zero-filled region not backed by any file. Used by malloc() for large allocations (glibc uses mmap for allocations >= 128KB by default).

MAP_SHARED vs MAP_PRIVATE:

MAP_SHARED: Changes are visible to all processes mapping the same file. msync() flushes changes to disk.
MAP_PRIVATE: Copy-on-write. Writes create private copies of pages. Changes are NOT written back to the file.

Always call munmap() to release the mapping.

Pseudo Code

File-backed mmap:
1. fd = open(file, O_RDWR)
2. ptr = mmap(NULL, size, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0)
3. Access ptr[i] as if it were an array
4. msync(ptr, size, MS_SYNC) to flush to disk
5. munmap(ptr, size)
6. close(fd)

Anonymous mmap:
1. ptr = mmap(NULL, size, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
2. Use ptr as heap memory
3. munmap(ptr, size)

Code

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/mman.h>
#include <sys/stat.h>

void file_backed_mmap(void) {
    int fd = open("testfile.txt", O_RDWR | O_CREAT | O_TRUNC, 0644);
    if (fd == -1) { perror("open"); return; }

    /* Extend file to desired size */
    const size_t size = 4096;
    ftruncate(fd, size);

    /* Map the file into memory */
    char *map = mmap(NULL, size, PROT_READ | PROT_WRITE,
                     MAP_SHARED, fd, 0);
    if (map == MAP_FAILED) { perror("mmap"); close(fd); return; }

    /* Write through the mapping */
    strcpy(map, "Hello via mmap!");
    printf("Read from mapping: %s\n", map);

    /* Flush to disk */
    msync(map, size, MS_SYNC);

    munmap(map, size);
    close(fd);
}

void anonymous_mmap(void) {
    /* Allocate 1MB of zeroed memory (no file backing) */
    size_t size = 1024 * 1024;
    int *arr = mmap(NULL, size, PROT_READ | PROT_WRITE,
                    MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
    if (arr == MAP_FAILED) { perror("mmap"); return; }

    /* Use like malloc'd memory */
    arr[0] = 42;
    printf("Anonymous mmap: arr[0] = %d\n", arr[0]);

    munmap(arr, size);
}

int main(void) {
    file_backed_mmap();
    anonymous_mmap();
    return 0;
}

Read from mapping: Hello via mmap!
Anonymous mmap: arr[0] = 42

Key Points

•mmap maps files into memory or creates anonymous (heap-like) regions
•MAP_SHARED: changes visible to others and written to file; MAP_PRIVATE: copy-on-write
•Anonymous mappings (MAP_ANONYMOUS) are used by malloc for large allocations
•mmap is faster than read/write for random-access file I/O
•Always munmap to release; msync to flush shared mappings to disk

Gotchas

•mmap returns MAP_FAILED (not NULL) on error -- check against MAP_FAILED, not NULL
•The file must be large enough for the mapping -- ftruncate() or write() to extend it first
•offset parameter must be page-aligned (multiple of page size)
•Accessing beyond the file size in a shared mapping causes SIGBUS, not SIGSEGV

mmap() maps files into memory or creates anonymous regions. MAP_SHARED writes back to the file; MAP_PRIVATE uses copy-on-write. Use munmap() to release, msync() to flush.

•MAP_SHARED = visible to others; MAP_PRIVATE = copy-on-write
•Check return against MAP_FAILED, not NULL

/* File-backed mmap */
char *p = mmap(NULL, 4096, PROT_READ|PROT_WRITE,
               MAP_SHARED, fd, 0);
strcpy(p, "Hello");  /* writes to the file */
munmap(p, 4096);

/* Anonymous mmap (like malloc) */
int *arr = mmap(NULL, size, PROT_READ|PROT_WRITE,
                MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
munmap(arr, size);

mmap returns MAP_FAILED on error, NOT NULL

Question 4 / 12

How does stack overflow occur and how can it be detected and prevented?

Stack overflow occurs when a program uses more stack space than allocated. The stack has a fixed size (default 8MB on Linux, configurable via ulimit -s).

Common causes:

Deep/infinite recursion: Each call adds a frame to the stack.
Large local arrays: char buf[10*1024*1024]; instantly overflows the stack.
Excessive function call depth: Even without recursion, deeply nested calls accumulate.

What happens:

The stack grows into a guard page (an unmapped page below the stack). Accessing it causes a SIGSEGV (segmentation fault).
On some systems, the kernel may expand the stack dynamically up to the limit. Beyond the limit, SIGSEGV.

Detection:

Compiler flags: -fstack-protector / -fstack-protector-strong insert canaries that detect buffer overflows on the stack.
Address Sanitizer: -fsanitize=address detects stack buffer overflows.
getrlimit(): Check the current stack size limit programmatically.

Prevention:

Move large arrays to the heap (malloc).
Convert recursion to iteration.
Increase stack size with ulimit -s or pthread_attr_setstacksize() for threads.
Use tail-call optimization (compiler may optimize tail-recursive functions, but C does not guarantee it).

Pseudo Code

Causes:
1. Infinite recursion: func() -> func() -> func() -> ...
2. Large local array: char buf[8MB]
3. Deep call chains

Prevention:
1. Move large data to heap (malloc)
2. Convert recursion to iteration
3. Increase stack limit (ulimit -s / pthread_attr_setstacksize)
4. Use -fstack-protector for overflow detection

Code

#include <stdio.h>
#include <stdlib.h>
#include <sys/resource.h>
#include <pthread.h>

/* Cause 1: Infinite recursion */
void infinite_recursion(int depth) {
    char buffer[4096]; /* 4KB per frame */
    buffer[0] = (char)depth;
    printf("Depth: %d, stack addr: %p\n", depth, (void *)buffer);
    infinite_recursion(depth + 1); /* Will crash ~2000 frames deep */
}

/* Prevention: convert recursion to iteration */
long factorial_iterative(int n) {
    long result = 1;
    for (int i = 2; i <= n; i++)
        result *= i;
    return result;
}

/* Prevention: move large data to heap */
void safe_large_buffer(void) {
    /* BAD: char buf[10 * 1024 * 1024]; -- stack overflow! */
    /* GOOD: */
    char *buf = malloc(10 * 1024 * 1024);
    if (buf) {
        buf[0] = 'A';
        free(buf);
    }
}

/* Check stack size limit */
void check_stack_limit(void) {
    struct rlimit rl;
    getrlimit(RLIMIT_STACK, &rl);
    printf("Stack soft limit: %lu KB\n", rl.rlim_cur / 1024);
    printf("Stack hard limit: %lu KB\n", rl.rlim_max / 1024);
}

/* Set thread stack size */
void *thread_func(void *arg) {
    (void)arg;
    printf("Thread running with custom stack\n");
    return NULL;
}

int main(void) {
    check_stack_limit();
    safe_large_buffer();

    /* Create thread with 16MB stack */
    pthread_t tid;
    pthread_attr_t attr;
    pthread_attr_init(&attr);
    pthread_attr_setstacksize(&attr, 16 * 1024 * 1024);
    pthread_create(&tid, &attr, thread_func, NULL);
    pthread_join(tid, NULL);
    pthread_attr_destroy(&attr);

    /* Uncomment to see stack overflow: */
    /* infinite_recursion(0); */

    return 0;
}

Stack soft limit: 8192 KB
Stack hard limit: <N> KB
Thread running with custom stack
(Stack limit values vary per system)

Key Points

•Default stack size is typically 8MB on Linux (check with ulimit -s)
•Stack overflow causes SIGSEGV when the stack grows into the guard page
•Common causes: deep recursion, large local arrays, excessive call depth
•Prevention: use heap for large data, convert recursion to iteration
•Use pthread_attr_setstacksize() to control per-thread stack size

Gotchas

•Stack overflow is not always caught cleanly -- the signal handler itself needs stack space (use sigaltstack)
•Compiler tail-call optimization is not guaranteed in C -- do not rely on it
•Thread stacks are typically smaller than the main thread stack (often 1-2MB by default)
•-fstack-protector detects buffer overflows on the stack but not stack exhaustion from deep recursion

Stack overflow happens when recursion or large local arrays exceed the stack limit (default 8MB). Causes SIGSEGV. Fix: use heap for large data, convert recursion to iteration, increase limit with ulimit -s.

•Default stack ~8MB; exceeded by deep recursion or large locals
•Fix: heap allocation or convert recursion to iteration

/* BAD: stack overflow */
char buf[10*1024*1024]; /* 10MB on stack -- crash! */

/* GOOD: use heap */
char *buf = malloc(10*1024*1024);

/* Check limit */
struct rlimit rl;
getrlimit(RLIMIT_STACK, &rl);
printf("Stack limit: %lu KB\n", rl.rlim_cur / 1024);

Thread stacks are often smaller (1-2MB) than the main thread stack

Question 5 / 12

How does the heap work internally (free lists and fragmentation)?

The heap is managed by the memory allocator (e.g., glibc's ptmalloc2, jemalloc, tcmalloc). The allocator sits between malloc()/free() calls and the OS.

Free list: The allocator maintains lists of free memory blocks. When you call malloc(size), it searches for a free block that fits. When you call free(ptr), the block is added back to a free list.

Allocation strategies:

First fit: Use the first block that is large enough. Fast but can cause fragmentation.
Best fit: Find the smallest block that fits. Reduces waste but slower.
Segregated free lists (glibc): Separate lists for different size classes (16, 32, 64, ... bytes). Fast because small allocations go to a specific bin.

Fragmentation:

External fragmentation: Free memory is split into small, non-contiguous blocks. Total free memory is enough, but no single block is large enough for the request.
Internal fragmentation: Allocated block is larger than requested (due to alignment/rounding). The extra space is wasted.

glibc ptmalloc2:

Small allocations (< 128KB): Uses sbrk() to extend the heap. Managed in bins.
Large allocations (>= 128KB): Uses mmap() directly. Freed with munmap().
Thread-local arenas: Reduce lock contention in multi-threaded programs.

Coalescing: When a block is freed, the allocator merges it with adjacent free blocks to reduce fragmentation.

Pseudo Code

malloc(size):
1. Round size up to alignment boundary
2. Search appropriate free list for a fitting block
3. If found: split block if much larger, return pointer
4. If not found: request more memory from OS (sbrk/mmap)
5. Return pointer to usable memory (after metadata header)

free(ptr):
1. Read metadata header before ptr to find block size
2. Mark block as free
3. Coalesce with adjacent free blocks
4. Add to appropriate free list
5. If large mmap'd block: munmap it back to OS

Code

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

/* Demonstrate fragmentation */
int main(void) {
    /* Allocate many small blocks */
    const int N = 1000;
    char *ptrs[1000];

    for (int i = 0; i < N; i++) {
        ptrs[i] = malloc(100); /* 100 bytes each */
    }
    printf("Allocated %d blocks of 100 bytes\n", N);

    /* Free every other block -- creates external fragmentation */
    for (int i = 0; i < N; i += 2) {
        free(ptrs[i]);
        ptrs[i] = NULL;
    }
    printf("Freed every other block (external fragmentation)\n");

    /* Now try to allocate a large block */
    /* This may fail or require new memory from OS even though
       500 * 100 = 50KB is free in scattered chunks */
    char *big = malloc(50000);
    if (big) {
        printf("Large allocation succeeded at %p\n", (void *)big);
        free(big);
    }

    /* Internal fragmentation: malloc(1) actually allocates
       at least 16-32 bytes due to alignment + metadata */
    char *tiny = malloc(1);
    printf("Asked for 1 byte, got block at %p\n", (void *)tiny);
    /* Real usable size is often 16+ bytes */

    /* Clean up */
    free(tiny);
    for (int i = 1; i < N; i += 2) {
        free(ptrs[i]);
    }

    return 0;
}

Allocated 1000 blocks of 100 bytes
Freed every other block (external fragmentation)
Large allocation succeeded at 0x<address>
Asked for 1 byte, got block at 0x<address>
(Addresses vary per run)

Key Points

•Allocator uses free lists organized by size (bins/buckets)
•External fragmentation: free memory is scattered in small chunks
•Internal fragmentation: allocated block is larger than requested (alignment overhead)
•glibc uses sbrk for small allocs, mmap for large (>= 128KB)
•Coalescing merges adjacent free blocks to reduce fragmentation

Gotchas

•free() does not always return memory to the OS -- it goes to the free list for reuse by future mallocs
•malloc(1) typically allocates 16-32 bytes due to alignment and metadata overhead
•Memory fragmentation can cause out-of-memory even when total free memory is sufficient
•malloc metadata is stored just before the returned pointer -- buffer overflows corrupt it, causing crashes in free()

The heap allocator maintains free lists of blocks by size. malloc() finds a fitting block; free() returns it. External fragmentation = scattered free blocks. Internal = wasted padding. glibc uses sbrk for small, mmap for large allocations.

•Free lists organized by size; coalescing merges adjacent free blocks
•free() returns to free list, not always to OS

/* External fragmentation demo */
char *a = malloc(100);
char *b = malloc(100);
char *c = malloc(100);
free(a);  /* free block between b and c */
free(c);  /* two free blocks, not contiguous */
/* malloc(200) might fail even though 200 bytes are free */
free(b);  /* now all 3 coalesce into one free block */

Buffer overflows corrupt malloc metadata, causing crashes in free()

Question 6 / 12

How do you use Valgrind (memcheck) for memory leak detection?

Valgrind is a dynamic analysis tool. Its Memcheck tool (the default) detects:

Memory leaks (allocated but never freed)
Use of uninitialized values
Reading/writing freed memory (use-after-free)
Reading/writing beyond allocated blocks (buffer overflow)
Double free
Mismatched alloc/free (malloc with delete, new with free)

Usage: Compile with -g (debug symbols) and -O0 (no optimization). Run:

valgrind --leak-check=full --show-reachable=yes --track-origins=yes ./program

Key flags:

--leak-check=full -- Show details of each leak.
--show-reachable=yes -- Show memory still reachable at exit.
--track-origins=yes -- Show where uninitialized values originated.
--log-file=valgrind.log -- Write output to a file.

Leak categories:

Definitely lost: No pointer to the block exists. Real leak.
Indirectly lost: Reachable only through a definitely-lost block.
Possibly lost: A pointer to the interior of the block exists (may be intentional).
Still reachable: Pointer exists at program exit (not a leak in most cases, just not freed before exit).

Performance: Valgrind runs the program in a virtual CPU. Expect 10-50x slowdown. Not suitable for production.

Pseudo Code

1. Compile: gcc -g -O0 -o prog prog.c
2. Run: valgrind --leak-check=full ./prog
3. Read report:
   - "Invalid read/write" = buffer overflow or use-after-free
   - "Conditional jump depends on uninitialised value" = uninitialized read
   - "X bytes in Y blocks are definitely lost" = memory leak
4. Fix the code and re-run until clean

Code

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

void memory_leak(void) {
    /* Leak: allocated but never freed */
    int *p = malloc(40);
    p[0] = 42;
    /* Missing: free(p); */
}

void use_after_free(void) {
    int *p = malloc(sizeof(int));
    *p = 10;
    free(p);
    /* BUG: using freed memory */
    /* printf("%d\n", *p); */  /* Valgrind: Invalid read */
}

void buffer_overflow(void) {
    int *arr = malloc(5 * sizeof(int));
    /* BUG: writing past the end */
    /* arr[5] = 99; */  /* Valgrind: Invalid write of size 4 */
    free(arr);
}

void uninitialized_read(void) {
    int x;
    /* BUG: using uninitialized variable */
    /* if (x > 0) printf("positive\n"); */
    /* Valgrind: Conditional jump depends on uninitialised value */
    x = 0; /* proper initialization */
    if (x > 0) printf("positive\n");
}

int main(void) {
    memory_leak();
    use_after_free();
    buffer_overflow();
    uninitialized_read();
    return 0;
}

/* Compile and run:
   gcc -g -O0 -o membugs membugs.c
   valgrind --leak-check=full --track-origins=yes ./membugs

   Expected output:
   ==PID== 40 bytes in 1 blocks are definitely lost
   ==PID==    at malloc (in libcXXX.so)
   ==PID==    by memory_leak (membugs.c:6)
   ==PID==    by main (membugs.c:33)
*/

Key Points

•Valgrind Memcheck detects leaks, use-after-free, buffer overflows, uninitialized reads
•Compile with -g -O0 for best results (debug symbols, no optimization)
•--leak-check=full shows detailed leak information with source locations
•Leak categories: definitely lost (real leak) vs still reachable (often benign)
•Expect 10-50x slowdown -- not for production use

Gotchas

•Valgrind cannot detect stack buffer overflows -- use Address Sanitizer for those
•Optimized code (-O2) may eliminate variables, making Valgrind reports confusing -- always use -O0
•Valgrind does not work on macOS ARM (Apple Silicon) -- use Address Sanitizer instead
•'Still reachable' is usually not a real leak -- it means memory was not freed before exit but was still accessible

Compile with -g -O0, run valgrind --leak-check=full ./prog. Detects leaks, use-after-free, buffer overflows, uninitialized reads. 10-50x slowdown.

•valgrind --leak-check=full detects leaks, use-after-free, overflows
•Compile with -g -O0 for readable reports

/* Compile: gcc -g -O0 -o prog prog.c */
/* Run: valgrind --leak-check=full --track-origins=yes ./prog */

/* Common bugs Valgrind finds: */
int *p = malloc(40);
/* leak: no free(p) */

free(p);
/* *p = 1;  -- use-after-free: Invalid write */

int *a = malloc(5 * sizeof(int));
/* a[5] = 1; -- buffer overflow: Invalid write */
free(a);

Valgrind does not detect stack overflows -- use ASan for those

Question 7 / 12

What are the essential GDB commands for debugging C programs?

GDB (GNU Debugger) is the standard debugger for C programs. Compile with -g for debug symbols.

Starting GDB:

gcc -g -O0 -o prog prog.c
gdb ./prog
gdb --args ./prog arg1 arg2

Essential commands:

Command	Short	Purpose
`run`	`r`	Start/restart the program
`break main`	`b main`	Set breakpoint at function
`break file.c:42`	`b file.c:42`	Breakpoint at line 42
`next`	`n`	Step over (execute line, don't enter functions)
`step`	`s`	Step into (enter called functions)
`continue`	`c`	Resume execution until next breakpoint
`print x`	`p x`	Print value of variable x
`print *ptr`	`p *ptr`	Dereference and print
`print arr[0]@10`		Print 10 elements of array
`backtrace`	`bt`	Show call stack (stack trace)
`frame 2`	`f 2`	Switch to stack frame #2
`watch x`		Break when variable x changes (hardware watchpoint)
`info locals`		Show all local variables
`info breakpoints`	`info b`	List all breakpoints
`delete 1`	`d 1`	Delete breakpoint #1
`quit`	`q`	Exit GDB

Debugging crashes: When a program crashes with SIGSEGV:

Run in GDB: gdb ./prog then run.
At crash: bt shows the exact call stack.
frame N and print var to inspect variables.
list shows source code around the current line.

Pseudo Code

1. Compile: gcc -g -O0 -o prog prog.c
2. gdb ./prog
3. (gdb) break main       -> set breakpoint
4. (gdb) run              -> start program
5. (gdb) next / step      -> step through code
6. (gdb) print variable   -> inspect values
7. (gdb) backtrace        -> see call stack on crash
8. (gdb) continue         -> resume to next breakpoint
9. (gdb) quit             -> exit

Code

#include <stdio.h>
#include <stdlib.h>

int divide(int a, int b) {
    /* Bug: no check for b == 0 */
    return a / b;
}

void process(int *data, int n) {
    for (int i = 0; i <= n; i++) { /* Bug: off by one (i <= n) */
        data[i] = i * 10;
    }
}

int main(void) {
    int result = divide(10, 2);
    printf("10 / 2 = %d\n", result);

    int *arr = malloc(5 * sizeof(int));
    if (!arr) return 1;
    process(arr, 5); /* Bug: writes arr[5] -- out of bounds */
    printf("arr[0] = %d\n", arr[0]);
    free(arr);

    /* Crash: NULL dereference */
    /* int *p = NULL; */
    /* *p = 42; */

    return 0;
}

/* GDB session example:
   $ gcc -g -O0 -o debug_me debug_me.c
   $ gdb ./debug_me
   (gdb) break main
   (gdb) run
   (gdb) next           # step over lines
   (gdb) print result   # inspect variable
   (gdb) break divide
   (gdb) continue       # run to divide()
   (gdb) print a        # 10
   (gdb) print b        # 2
   (gdb) backtrace      # show call stack
   (gdb) watch result   # break when result changes
   (gdb) info locals    # all local vars in current frame
   (gdb) quit
*/

10 / 2 = 5
arr[0] = 0

Key Points

•Compile with -g -O0 for debug symbols and no optimization
•break, run, next, step, continue, print, backtrace are the core commands
•backtrace (bt) shows the full call stack -- essential for crash debugging
•watch sets a hardware watchpoint that breaks when a variable changes
•info locals shows all local variables in the current stack frame

Gotchas

•Optimized code (-O2) may reorder or eliminate variables, making GDB output confusing -- always use -O0 for debugging
•GDB cannot debug stripped binaries (no debug symbols) -- always compile with -g
•Breakpoints on inlined functions may not work as expected with optimization
•On macOS, use lldb instead of gdb (gdb requires code signing on modern macOS)

Compile with -g -O0. Core GDB commands: break (set breakpoint), run, next/step (step over/into), print (inspect), backtrace (call stack), continue, quit.

•break, run, next, step, print, backtrace, continue, quit
•Always compile with -g -O0

/* Compile: gcc -g -O0 -o prog prog.c */
/* gdb ./prog */
/* (gdb) break main */
/* (gdb) run */
/* (gdb) next          -- step over */
/* (gdb) step          -- step into */
/* (gdb) print var     -- inspect */
/* (gdb) backtrace     -- call stack */
/* (gdb) continue      -- resume */
/* (gdb) quit */

Use lldb instead of gdb on macOS

Question 8 / 12

How does Address Sanitizer (ASan) work and what does it detect?

Address Sanitizer (ASan) is a compile-time instrumentation tool that detects memory errors at runtime. It is built into GCC and Clang.

Usage: gcc -fsanitize=address -g -O1 -o prog prog.c

What ASan detects:

Heap buffer overflow -- Read/write past malloc'd region.
Stack buffer overflow -- Read/write past local arrays.
Global buffer overflow -- Read/write past global arrays.
Use-after-free -- Accessing memory after free().
Use-after-return -- Accessing a local variable after the function returns (with -fsanitize-address-use-after-return=always).
Double free -- Calling free() twice on the same pointer.
Memory leaks -- With -fsanitize=address,leak or ASAN_OPTIONS=detect_leaks=1.

How it works:

ASan inserts redzones (poisoned memory) around every stack, heap, and global object.
It maintains a shadow memory that tracks which bytes are valid/poisoned.
Every memory access is instrumented to check the shadow memory first.
If an access hits a redzone, ASan reports the error with a stack trace.

Performance: ~2x slowdown, ~2-3x memory overhead. Much faster than Valgrind.

Advantages over Valgrind:

Detects stack and global overflows (Valgrind cannot).
Much faster (2x vs 10-50x).
Works on macOS ARM (Apple Silicon).

Pseudo Code

Compilation:
1. gcc -fsanitize=address -g -o prog prog.c

ASan instrumentation (conceptual):
  For every memory access *addr:
  1. Check shadow_mem[addr] -- is it poisoned?
  2. If poisoned: print error + stack trace + abort
  3. If clean: allow the access

Redzone layout for malloc(10):
  [redzone][10 usable bytes][redzone]
  Writing to redzone triggers ASan error

Code

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

/* Bug 1: Heap buffer overflow */
void heap_overflow(void) {
    int *arr = malloc(5 * sizeof(int));
    arr[5] = 42; /* ASan: heap-buffer-overflow */
    free(arr);
}

/* Bug 2: Stack buffer overflow */
void stack_overflow(void) {
    int buf[5];
    buf[5] = 42; /* ASan: stack-buffer-overflow */
}

/* Bug 3: Use-after-free */
void use_after_free(void) {
    int *p = malloc(sizeof(int));
    *p = 10;
    free(p);
    printf("%d\n", *p); /* ASan: heap-use-after-free */
}

/* Bug 4: Double free */
void double_free(void) {
    int *p = malloc(sizeof(int));
    free(p);
    free(p); /* ASan: double-free */
}

int main(void) {
    /* Uncomment one at a time to see ASan output */
    /* heap_overflow(); */
    /* stack_overflow(); */
    /* use_after_free(); */
    /* double_free(); */
    printf("No bugs triggered\n");
    return 0;
}

/* Compile and run:
   gcc -fsanitize=address -g -O1 -o asan_demo asan_demo.c
   ./asan_demo

   ASan output example:
   ==PID==ERROR: AddressSanitizer: heap-buffer-overflow
   WRITE of size 4 at 0x....
   #0 heap_overflow asan_demo.c:6
   #1 main asan_demo.c:26
*/

No bugs triggered

Key Points

•Compile with -fsanitize=address -g to enable ASan
•Detects heap/stack/global overflows, use-after-free, double-free
•Uses shadow memory and redzones to catch invalid accesses
•~2x slowdown (much faster than Valgrind's 10-50x)
•Works on macOS ARM where Valgrind does not

Gotchas

•ASan cannot be used simultaneously with Valgrind -- choose one
•ASan increases memory usage by 2-3x due to shadow memory and redzones
•-O1 or higher is recommended with ASan -- -O0 may produce false positives or miss some bugs
•ASan does not detect uninitialized reads -- use -fsanitize=memory (MSan) for that, but MSan only works on Linux

Compile with -fsanitize=address -g. Detects heap/stack/global overflows, use-after-free, double-free. ~2x slowdown. Faster and more capable than Valgrind for many bug types.

•-fsanitize=address detects overflows, use-after-free, double-free
•~2x slowdown, catches stack overflows (Valgrind cannot)

/* gcc -fsanitize=address -g -O1 -o prog prog.c */

int *p = malloc(5 * sizeof(int));
p[5] = 42;  /* ASan: heap-buffer-overflow */
free(p);
*p = 10;    /* ASan: heap-use-after-free */
free(p);    /* ASan: double-free */

ASan does not detect uninitialized reads -- use MSan for that

Question 9 / 12

What are memory barriers and why are they needed (compiler vs hardware ordering)?

Memory barriers (fences) prevent the reordering of memory operations. Reordering happens at two levels:

1. Compiler reordering: The compiler rearranges instructions for optimization. It can move loads and stores as long as the single-threaded result is unchanged. But in multi-threaded code, this can break assumptions about memory visibility.

Compiler barrier: asm volatile("" ::: "memory") (GCC/Clang). Tells the compiler not to reorder memory operations across this point. Does NOT affect the CPU.

2. Hardware reordering: Modern CPUs reorder instructions out-of-order for performance. On weakly-ordered architectures (ARM, POWER), a store by CPU 0 may not be visible to CPU 1 immediately, or loads/stores may appear in different order.

Hardware memory barriers:

__sync_synchronize() -- Full hardware barrier (GCC built-in).
atomic_thread_fence(memory_order_seq_cst) -- C11 full barrier.
atomic_thread_fence(memory_order_acquire) -- Acquire barrier (loads after this see prior stores from other threads).
atomic_thread_fence(memory_order_release) -- Release barrier (stores before this are visible to other threads that acquire).

x86 is strongly ordered: Stores are not reordered with other stores, and loads are not reordered with other loads. But StoreLoad reordering IS possible (a load can be reordered before an earlier store to a different address). mfence prevents this.

ARM/POWER are weakly ordered: All types of reordering are possible. Barriers are essential.

volatile is NOT a memory barrier: It prevents the compiler from caching a variable in a register, but does NOT prevent reordering of surrounding accesses.

Pseudo Code

Problem (without barrier):
  Thread 1:            Thread 2:
  data = 42;           while (!ready);  /* spin */
  ready = 1;           use(data);       /* may see data=0! */

Compiler/CPU may reorder: ready=1 before data=42

Fix with barrier:
  Thread 1:            Thread 2:
  data = 42;           while (!ready);  /* spin */
  BARRIER;             BARRIER;
  ready = 1;           use(data);       /* now safe */

Code

#include <stdio.h>
#include <stdatomic.h>
#include <pthread.h>

/* Shared state */
int data = 0;
atomic_int ready = 0;

void *producer(void *arg) {
    (void)arg;
    data = 42;
    /* Release fence: ensures data=42 is visible before ready=1 */
    atomic_thread_fence(memory_order_release);
    atomic_store_explicit(&ready, 1, memory_order_relaxed);
    return NULL;
}

void *consumer(void *arg) {
    (void)arg;
    while (atomic_load_explicit(&ready, memory_order_relaxed) == 0)
        ; /* spin */
    /* Acquire fence: ensures we see all stores before the release */
    atomic_thread_fence(memory_order_acquire);
    printf("data = %d\n", data); /* Guaranteed to print 42 */
    return NULL;
}

int main(void) {
    pthread_t t1, t2;
    pthread_create(&t1, NULL, producer, NULL);
    pthread_create(&t2, NULL, consumer, NULL);
    pthread_join(t1, NULL);
    pthread_join(t2, NULL);
    return 0;
}

/* Compiler barrier only (GCC/Clang): */
/* asm volatile("" ::: "memory"); */

/* Full hardware barrier (GCC built-in): */
/* __sync_synchronize(); */

/* C11 atomics are preferred for portable code */

data = 42

Key Points

•Compiler barriers prevent compiler reordering; hardware barriers prevent CPU reordering
•C11 atomic_thread_fence provides portable memory barriers
•Acquire fence: loads after it see stores before the matching release fence
•Release fence: stores before it are visible to threads that do an acquire
•x86 is strongly ordered (only StoreLoad reordering); ARM/POWER are weakly ordered

Gotchas

•volatile does NOT provide memory barrier semantics -- it only prevents register caching
•On x86, most barriers are implicit (strong ordering) but StoreLoad reordering can still bite you
•Missing barriers cause bugs that appear only under heavy load or on specific CPUs -- extremely hard to debug
•Prefer C11 atomics (stdatomic.h) over raw barriers -- they combine the variable access with the correct barrier

Memory barriers prevent reordering of memory ops by the compiler (compiler barrier) or CPU (hardware barrier). Use C11 atomic_thread_fence() or __sync_synchronize(). volatile is NOT a memory barrier.

•Compiler barrier: asm volatile("" ::: "memory")
•C11 atomic fences are the portable solution

/* Compiler barrier (GCC/Clang) */
asm volatile("" ::: "memory");

/* Full hardware barrier */
__sync_synchronize();

/* C11 portable barriers */
#include <stdatomic.h>
atomic_thread_fence(memory_order_release); /* before store */
atomic_thread_fence(memory_order_acquire); /* after load */

volatile is NOT a memory barrier

Question 10 / 12

What is cache-friendly programming and locality of reference in C?

Modern CPUs have multi-level caches (L1: ~32KB, L2: ~256KB, L3: ~8MB). A cache miss (accessing data not in cache) costs 100+ cycles versus ~4 cycles for a cache hit. Writing cache-friendly code means organizing memory access patterns to maximize cache hits.

Locality of reference:

Temporal locality: If you access address X, you are likely to access X again soon. Keep working sets small.
Spatial locality: If you access X, you are likely to access X+1, X+2 soon. Access memory sequentially.

Cache line: The unit of data transferred between cache and memory. Typically 64 bytes on x86. Accessing one byte loads the entire 64-byte cache line.

Key principles:

Access arrays sequentially (row-major order in C). A 2D array arr[i][j] should be traversed with the inner loop over j (consecutive memory).
Use small, compact data structures. Avoid unnecessary padding. Use arrays of structs (AoS) vs structs of arrays (SoA) depending on access pattern.
Avoid pointer chasing. Linked lists have poor locality (nodes scattered in heap). Prefer arrays.
Keep hot data together. Frequently accessed fields should be in the same struct (same cache line).
Avoid false sharing: Two threads writing to different variables on the same cache line cause cache-line bouncing. Align per-thread data to cache line boundaries.

Pseudo Code

Bad (column-major traversal of row-major array):
  for j in 0..cols:     /* stride = row_size (cache misses) */
    for i in 0..rows:
      access arr[i][j]

Good (row-major traversal):
  for i in 0..rows:     /* stride = 1 (sequential, cache-friendly) */
    for j in 0..cols:
      access arr[i][j]

Code

#include <stdio.h>
#include <stdlib.h>
#include <time.h>

#define N 2048
static int matrix[N][N];

/* BAD: Column-major traversal (cache-unfriendly) */
long sum_column_major(void) {
    long sum = 0;
    for (int j = 0; j < N; j++)       /* outer loop over columns */
        for (int i = 0; i < N; i++)   /* inner loop over rows */
            sum += matrix[i][j];      /* stride = N * sizeof(int) */
    return sum;
}

/* GOOD: Row-major traversal (cache-friendly) */
long sum_row_major(void) {
    long sum = 0;
    for (int i = 0; i < N; i++)       /* outer loop over rows */
        for (int j = 0; j < N; j++)   /* inner loop over columns */
            sum += matrix[i][j];      /* stride = sizeof(int) */
    return sum;
}

/* Struct of Arrays (SoA) -- good when accessing one field at a time */
struct particles_soa {
    float x[1000];
    float y[1000];
    float z[1000];
    float mass[1000];
};

/* Array of Structs (AoS) -- good when accessing all fields of one item */
struct particle_aos {
    float x, y, z, mass;
};
struct particle_aos particles[1000];

int main(void) {
    /* Initialize */
    for (int i = 0; i < N; i++)
        for (int j = 0; j < N; j++)
            matrix[i][j] = 1;

    clock_t start, end;

    start = clock();
    long s1 = sum_row_major();
    end = clock();
    printf("Row-major:    %ld (%.3f ms)\n", s1,
           1000.0 * (end - start) / CLOCKS_PER_SEC);

    start = clock();
    long s2 = sum_column_major();
    end = clock();
    printf("Column-major: %ld (%.3f ms)\n", s2,
           1000.0 * (end - start) / CLOCKS_PER_SEC);
    /* Row-major is typically 3-10x faster for large N */

    return 0;
}

Row-major:    4194304 (<X> ms)
Column-major: 4194304 (<Y> ms)
(Times vary; row-major is typically 3-10x faster)

Key Points

•Cache line is 64 bytes -- accessing one byte loads 64 bytes
•Row-major (sequential) traversal is cache-friendly; column-major causes cache misses
•Spatial locality: access contiguous memory; temporal locality: reuse data soon
•Arrays are cache-friendly; linked lists are not (pointer chasing)
•False sharing: threads writing to same cache line causes performance degradation

Gotchas

•Column-major traversal of a large 2D array can be 3-10x slower than row-major
•Linked lists have terrible cache performance for traversal -- prefer arrays when possible
•False sharing between threads is invisible in code but devastating for performance -- pad per-thread data to 64 bytes
•Struct field ordering matters: putting hot fields first keeps them in the same cache line

Access memory sequentially (row-major for 2D arrays). Cache line = 64 bytes. Spatial locality (sequential access) and temporal locality (reuse data) maximize cache hits. Avoid pointer chasing (linked lists).

•Sequential access = cache-friendly; large strides = cache misses
•Cache line is 64 bytes; arrays beat linked lists for locality

/* GOOD: row-major (cache-friendly) */
for (int i = 0; i < N; i++)
    for (int j = 0; j < N; j++)
        sum += arr[i][j]; /* sequential memory access */

/* BAD: column-major (cache-unfriendly) */
for (int j = 0; j < N; j++)
    for (int i = 0; i < N; i++)
        sum += arr[i][j]; /* large stride, cache misses */

Column-major traversal can be 3-10x slower for large arrays

Question 11 / 12

How do brk() and sbrk() work and how does malloc use them?

brk() and sbrk() are the low-level system calls that adjust the program break -- the end of the data segment (top of the heap).

int brk(void *addr): Sets the program break to addr. Returns 0 on success, -1 on error.

void *sbrk(intptr_t increment): Increases the program break by increment bytes. Returns the previous program break (the start of the new memory). sbrk(0) returns the current break without changing it.

How malloc uses them:

For small allocations (< MMAP_THRESHOLD, typically 128KB), glibc's malloc calls sbrk() to extend the heap. The allocator carves blocks from this region.
For large allocations (>= 128KB), malloc uses mmap() instead. This avoids fragmenting the heap and allows the memory to be returned to the OS immediately via munmap().
free() for sbrk-allocated memory adds the block to a free list. The memory is NOT returned to the OS unless the freed block is at the very top of the heap (then brk() can lower the break).

Why not call sbrk() directly? You must not mix sbrk() with malloc() -- they both manage the same heap region. Calling sbrk() directly while using malloc() corrupts the allocator's internal state.

Modern note: On modern systems, brk/sbrk are considered obsolete. The kernel and allocators increasingly rely on mmap() for all allocations.

Pseudo Code

sbrk(0)         -> returns current program break
sbrk(4096)      -> extends heap by 4096 bytes, returns old break
brk(old + 8192) -> sets break to specific address

malloc(size):
  if size < 128KB:
    use sbrk to extend heap, carve block from it
  else:
    use mmap for a private anonymous mapping

free(ptr):
  if sbrk-allocated: add to free list (stays in process)
  if mmap-allocated: munmap (returns to OS immediately)

Code

#include <stdio.h>
#include <unistd.h>
#include <stdint.h>

int main(void) {
    /* Get current program break */
    void *initial_brk = sbrk(0);
    printf("Initial program break: %p\n", initial_brk);

    /* Extend heap by 4096 bytes */
    void *old_brk = sbrk(4096);
    if (old_brk == (void *)-1) {
        perror("sbrk");
        return 1;
    }
    printf("Old break: %p\n", old_brk);
    printf("New break: %p\n", sbrk(0));
    printf("Difference: %td bytes\n",
           (char *)sbrk(0) - (char *)old_brk);

    /* Use the allocated memory */
    int *arr = (int *)old_brk;
    for (int i = 0; i < 100; i++) {
        arr[i] = i * i;
    }
    printf("arr[10] = %d\n", arr[10]); /* 100 */

    /* Shrink heap back (return memory) */
    brk(initial_brk);
    printf("Break restored to: %p\n", sbrk(0));

    /* WARNING: Do NOT mix sbrk() with malloc()! */
    /* malloc uses sbrk internally -- direct sbrk calls
       corrupt malloc's data structures */

    return 0;
}

Initial program break: 0x<address>
Old break: 0x<address>
New break: 0x<address>
Difference: 4096 bytes
arr[10] = 100
Break restored to: 0x<address>
(Addresses vary per run)

Key Points

•sbrk(n) extends heap by n bytes, returns pointer to new region
•brk(addr) sets the program break to a specific address
•malloc uses sbrk for small allocs (< 128KB), mmap for large ones
•free() of sbrk memory goes to free list, not back to OS (usually)
•sbrk(0) returns current break without changing it

Gotchas

•NEVER mix direct sbrk() calls with malloc() -- it corrupts the allocator's internal state
•sbrk returns (void *)-1 on failure, not NULL -- check correctly
•brk/sbrk are considered obsolete -- mmap is preferred for new allocator designs
•free() rarely returns sbrk memory to the OS -- only if the freed block is at the top of the heap

sbrk(n) extends the heap by n bytes, returning the old break. brk(addr) sets the break directly. malloc uses sbrk for small allocs, mmap for large ones. Never mix sbrk with malloc.

•sbrk extends heap; brk sets it to an absolute address
•malloc uses sbrk for small allocs, mmap for large ones

void *cur = sbrk(0);       /* current program break */
void *new = sbrk(4096);    /* extend heap by 4096 bytes */
int *arr = (int *)new;     /* use the memory */
arr[0] = 42;
brk(cur);                  /* shrink back (return memory) */

Never call sbrk directly if you also use malloc -- it corrupts internal state

Question 12 / 12

What are common memory corruption patterns in C (buffer overflow, use-after-free, double-free)?

Memory corruption bugs are the most dangerous class of C bugs. They cause crashes, data corruption, and security vulnerabilities.

1. Buffer overflow (heap/stack): Writing past the end of an allocated buffer. On the stack, this can overwrite the return address (enabling code execution attacks). On the heap, it corrupts allocator metadata or adjacent objects.

2. Use-after-free (UAF): Accessing memory after free(). The memory may have been reallocated to another object, so reading returns garbage and writing corrupts unrelated data. This is a major source of exploitable security bugs.

3. Double free: Calling free() twice on the same pointer. Corrupts the allocator's free list. Can lead to the allocator returning the same memory for two different malloc() calls, causing one object to alias another.

4. Uninitialized memory read: Reading a variable before assigning it. The value is whatever was in that memory location before -- garbage. Can leak sensitive data (information disclosure).

5. Null pointer dereference: Dereferencing a NULL pointer causes SIGSEGV. Always check malloc's return value.

6. Type confusion / incorrect cast: Casting a pointer to the wrong type and accessing it. Violates strict aliasing and causes undefined behavior.

Prevention:

Use ASan (-fsanitize=address) during development.
Run Valgrind in CI.
Set freed pointers to NULL (free(p); p = NULL;).
Use safe string functions (snprintf instead of sprintf, strncpy or strlcpy instead of strcpy).
Enable -Wall -Wextra -Werror.

Pseudo Code

Pattern 1 - Buffer overflow:
  char buf[10]; strcpy(buf, "this string is way too long");

Pattern 2 - Use-after-free:
  free(p); ... *p = 42;  /* p is dangling */

Pattern 3 - Double free:
  free(p); ... free(p);  /* corrupts allocator */

Pattern 4 - Uninitialized read:
  int x; if (x > 0) ...  /* x is garbage */

Prevention:
  - ASan (-fsanitize=address)
  - Set freed pointers to NULL
  - Bounds checking
  - -Wall -Wextra -Werror

Code

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

/* 1. Buffer overflow */
void buffer_overflow_demo(void) {
    char buf[10];
    /* BUG: "Hello World!" is 12 chars + null = 13 > 10 */
    /* strcpy(buf, "Hello World!"); */
    /* SAFE: use snprintf */
    snprintf(buf, sizeof(buf), "Hello World!");
    printf("%s\n", buf); /* "Hello Wor" (truncated safely) */
}

/* 2. Use-after-free */
void use_after_free_demo(void) {
    int *p = malloc(sizeof(int));
    *p = 42;
    free(p);
    /* BUG: p is dangling -- memory may be reused */
    /* printf("%d\n", *p); */
    /* FIX: set to NULL after free */
    p = NULL;
    /* Now *p would crash immediately (easier to debug) */
}

/* 3. Double free */
void double_free_demo(void) {
    int *p = malloc(sizeof(int));
    free(p);
    /* BUG: free(p); -- corrupts allocator */
    /* FIX: set to NULL after free */
    p = NULL;
    free(p); /* free(NULL) is safe -- no-op */
}

/* 4. Safe free macro */
#define SAFE_FREE(ptr) do { free(ptr); (ptr) = NULL; } while(0)

/* 5. Bounds-checked access */
int safe_array_get(const int *arr, int size, int index) {
    if (index < 0 || index >= size) {
        fprintf(stderr, "Index %d out of bounds [0, %d)\n", index, size);
        return -1;
    }
    return arr[index];
}

int main(void) {
    buffer_overflow_demo();
    use_after_free_demo();
    double_free_demo();

    int arr[] = {10, 20, 30};
    printf("arr[1] = %d\n", safe_array_get(arr, 3, 1));
    safe_array_get(arr, 3, 5); /* prints error, returns -1 */

    /* Using SAFE_FREE */
    int *data = malloc(100);
    SAFE_FREE(data); /* frees and sets to NULL */
    SAFE_FREE(data); /* safe: free(NULL) is a no-op */

    return 0;
}

Hello Wor
arr[1] = 20
Array index 5 out of bounds
(snprintf truncates 'Hello World!' to 9 chars + null)

Key Points

•Buffer overflow: writing past array bounds -- use snprintf, strncpy, bounds checks
•Use-after-free: accessing freed memory -- set pointers to NULL after free
•Double free: calling free twice -- set pointer to NULL (free(NULL) is safe)
•Use ASan and Valgrind to detect these bugs during development
•Enable -Wall -Wextra -Werror to catch issues at compile time

Gotchas

•Use-after-free bugs may 'work' for a long time because the freed memory is not immediately reused -- they are time bombs
•Buffer overflows on the stack can overwrite the return address, enabling arbitrary code execution (the basis of most exploits)
•Double free corrupts the allocator's free list and can lead to arbitrary write primitives (security-critical)
•strncpy does not null-terminate if the source is longer than n -- always add buf[n-1] = '\0' explicitly

Main corruption patterns: buffer overflow (write past bounds), use-after-free (access freed memory), double free (free twice). Fix: bounds-check, NULL after free, use ASan/Valgrind, -Wall -Wextra.

•NULL pointer after free prevents use-after-free and double-free
•snprintf is the safe alternative to sprintf/strcpy

/* Safe free macro */
#define SAFE_FREE(p) do { free(p); (p) = NULL; } while(0)

char buf[10];
snprintf(buf, sizeof(buf), "%s", long_str); /* safe, truncates */

int *p = malloc(100);
SAFE_FREE(p);   /* frees and NULLs */
SAFE_FREE(p);   /* safe: free(NULL) is no-op */

Use-after-free may appear to work for a long time before suddenly crashing

Built by onllm.dev

Home GitHub Support awesomePrep