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

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.

I would choose the synchronization strategy based on correctness first, then latency. A mutex is still the right answer when several fields must change together and the object has an invariant that must never be observed half-updated. If the critical section is tiny but contention is high, the problem may be the lock, or it may be the layout around the lock.

Decision guide:

• Keep the mutex if updates must be atomic across multiple fields.
• Change the data layout if the lock is not the bottleneck but cache contention is.
• Use atomics if the state is just one or a few independent values, like counters or a version number.

Concrete example: suppose the shared object holds requests, errors, and last_seen_ms. I might make requests and errors atomic counters, but keep a mutex for updating last_seen_ms together with other correlated state. That reduces lock traffic without weakening correctness.

What I would check in practice: contention rate, p95 or p99 latency under load, and whether threads are bouncing the same cache line. If the mutex is simple and the real issue is false sharing, padding or splitting the object can help more than replacing the lock. If the state machine is complex, I would prefer the clear mutex design over a fragile lock-free rewrite.

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.

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

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.