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

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.

I would suspect a lifetime bug first. If a function returns a pointer and the crash happens only after the function has finished, the pointer may refer to memory that no longer exists, such as a stack local, freed heap memory, or a temporary object.

What I would inspect in the code:

• return &local_variable; or returning a pointer into a local array.
• Returning c_str() from a temporary string.
• Freeing or reusing the buffer before the caller is done.
• Ownership comments that do not match the implementation.

How I would debug it:

• Rebuild with AddressSanitizer and run the failing path.
• Print the pointer value and compare it to stack and heap regions.
• Set a breakpoint right after the function returns and see whether the caller still dereferences the same address.
• Check whether the bug disappears under debug because stack layout changes.

Concrete example: this is broken:
char buf[64]; return buf;
The caller gets a pointer to a stack frame that disappears when the function returns.

Root cause confirmation: if ASan reports use-after-scope or use-after-free, that confirms lifetime, not a random crash. The fix is to return by value, transfer ownership clearly, or have the caller provide the buffer.

The slowdown smells like cache-coherence overhead, especially false sharing. False sharing happens when threads update different variables that happen to live on the same cache line. A cache line is the unit of memory moved between cores, so even independent counters can fight each other if they sit next to each other in one shared struct.

How I would investigate:

• Profile CPU time and hardware counters for cache misses and coherence traffic.
• Inspect the status object layout to see whether per-thread counters are adjacent.
• Check for atomic read-modify-write operations, which can be expensive under contention.
• Verify the machine is not also hitting NUMA effects or memory bandwidth limits.

Concrete example: if 8 threads each increment a different int in one status object, and those ints fit on the same cache line, every increment can invalidate the line for the other cores. Adding more threads then makes the line bounce more, so throughput gets worse.

Typical fixes: give each thread its own counter, pad hot fields so they do not share a line, aggregate locally and publish less often, or move to thread-local storage. If the counters must be shared, I would try to reduce update frequency before I add more synchronization. When scaling gets worse with more cores, shared-memory traffic is usually the first thing I suspect.

A pointer-to-pointer loop makes this clean. The key idea is that cur always points to the link that leads to the current node, so deleting the head uses the same code as deleting any other node.

#include <stdlib.h>

struct Node {
    int value;
    struct Node *next;
};

struct Node *remove_all(struct Node *head, int target) {
    struct Node **cur = &head;

    while (*cur) {
        if ((*cur)->value == target) {
            struct Node *dead = *cur;
            *cur = dead->next;
            free(dead);
        } else {
            cur = &(*cur)->next;
        }
    }

    return head;
}

Concrete example: for 5 -> 2 -> 2 -> 7 with target 2, the function frees both matching nodes and returns 5 -> 7. Time is O(n), space is O(1).

This is usually copy-on-write, which is expected behavior after fork. Copy-on-write means the parent and child initially share the same physical memory pages. The kernel copies a page only when one process writes to it. So a memory spike right after fork often reflects accounting or page faults, not a full duplicate of the whole heap.

What I would inspect:

• RSS versus PSS. RSS can make both processes look large, while PSS shows shared memory more honestly.
• /proc/<pid>/smaps to see private dirty pages.
• Page-fault counts and whether the child writes to large regions of memory.
• Whether huge pages or allocator arenas are causing more pages to be copied than expected.

Concrete example: if the parent has a 4 GB heap and the child reads only, the child does not get 4 GB of new physical memory. If the child writes to 100 MB of pages, then roughly that much becomes private to the child.

How I would judge it: if RSS jumps but PSS stays stable and the child exits quickly, the spike is probably expected. If private dirty memory keeps growing, the child is touching too much state and the fork pattern may need redesign, such as using a worker pool or reducing the amount of writable memory inherited at fork time.