Language-Level Memory Management (C/C++/Rust) Questions

I would treat this as a heap-corruption hunt, not a crash hunt. Heap corruption usually happens earlier than the visible failure, so I want the first bad write, not the last symptom.

What I would instrument first:

• A sanitizer build in staging, especially AddressSanitizer, because it reports the exact out-of-bounds write or use-after-free.
• A thin malloc/free/realloc wrapper that logs pointer, size, and call site for the large-request path.
• Guard checks around the suspicious buffers, for example canary bytes before and after a large allocation.

Concrete example: if the service fails after a 64 KB upload, I would log every allocation made while parsing that request and compare a good run to a bad run. If the crash disappears under a sanitizer build, I know the bug is timing-sensitive, and I keep narrowing by request size and code path until one suspicious write shows up.

I would not start with the final crash stack alone, because heap corruption often makes the crash happen far away from the real bug.

I would separate objects by lifetime, not just by type. Short-lived objects should go into an arena or pool that can be reset in bulk, while long-lived objects should live in a separate pool or the normal heap. That prevents short-lived churn from fragmenting memory used by long-lived data.

Trade-offs:

• Arena or pool allocation is fast and very cache-friendly, because objects are close together in memory.
• Bulk release is cheap, but you usually cannot free one object at a time.
• General heap allocation is flexible, but it can fragment more and adds allocator overhead.

Concrete example: if I have 10,000,000 objects at 32 bytes each, that is about 320 MB. If most of those objects live for only one request, allocating them from a per-request arena keeps the hot data contiguous and avoids millions of individual frees.

What matters most: latency, fragmentation, and cache locality. For hot lookup paths, contiguous memory usually wins because fewer cache misses happen. For long-lived objects that are accessed often, I would still prefer a stable pool so their addresses stay predictable. If objects are shared across threads, I would also consider thread-local pools to avoid allocator contention. The key is matching the allocator to the lifetime pattern instead of using one strategy for everything.

What is happening is a use-after-return. The local array lives on the stack, and that stack frame is destroyed when the function returns. The struct keeps a pointer to memory that no longer belongs to it, so the next read can see overwritten stack data or crash outright.

In code review, I would look for any address of a local variable or local array being stored into a field that escapes the function, especially if the function returns that struct. A line like s.buf = tmp; where tmp is char tmp[32]; is the red flag.

The API rule I would change is ownership: either the struct owns heap memory and provides a destroy function, or it clearly borrows memory that must outlive the struct. Mixing the two is the bug. For a returned struct, I would prefer deep-copying the data into owned storage and documenting that the caller must free it later.

Concrete example: char tmp[16] is valid only inside the function. After return, s.buf points into dead stack space, so reading s.buf[0] is undefined behavior.

I would raise three issues: alignment, strict aliasing, and endianness. Alignment means some CPUs require a uint32_t * to start on a 4-byte boundary. Strict aliasing means the compiler assumes pointers to unrelated types do not point to the same object, so casting a uint8_t * buffer and dereferencing it can miscompile under optimization. Endianness means byte order differs between CPUs.

A raw byte buffer is not automatically a real uint32_t object, so the safe pattern is to copy, not cast:

#include <stdint.h>
#include <string.h>

uint32_t word;
memcpy(&word, p, sizeof word);

Then convert from the protocol's byte order explicitly if needed. To prove the cast is not safe, I would test on a strict-alignment target, build with sanitizers or warnings like cast alignment, and compare the optimized build against the memcpy version. If behavior changes, the cast was relying on undefined behavior.

To solve this, I would use realloc with a temporary pointer so a failed growth leaves the original array untouched. realloc is the standard resizing allocator: it may move the block, but on failure the old block is still valid.

#include <stdlib.h>
#include <stdint.h>

int append_int(int **data, size_t *len, size_t *cap, int value) {
    size_t new_cap;
    int *tmp;

    if (!data || !len || !cap || *len > *cap) return -1;

    if (*len == *cap) {
        new_cap = (*cap == 0) ? 4 : (*cap * 2);
        if (new_cap < *cap) return -1;
        if (new_cap < *len + 1) new_cap = *len + 1;
        if (new_cap > SIZE_MAX / sizeof(int)) return -1;

        tmp = realloc(*data, new_cap * sizeof(int));
        if (!tmp) return -1;

        *data = tmp;
        *cap = new_cap;
    }

    (*data)[*len] = value;
    (*len)++;
    return 0;
}

Example: if len = 3 and cap = 4, appending 9 stores it at index 3 with no resize. If len = 4 and cap = 4, the function grows to 8, preserves the first 4 integers, and only then appends. Time is amortized O(1), with O(n) work only on resize.