## TL;DR
A C kernel has no garbage collector to save it: allocating past the machine's RAM gets the process killed by the OOM killer, and the UI just says the kernel died. Confirm the limit with `ulimit -v` and the container memory cap, then restructure the code to allocate in bounded chunks or memory-map the data instead of loading it. The fix is in the allocation pattern, not the kernel.

```text
C kernel keeps dying: crash when allocating beyond available RAM
```

## Use this when
- A C (or other native-language) kernel dies when allocating large buffers.
- The same logic works on smaller inputs.
- dmesg shows the OOM killer took the kernel process.

## Not for this skill when
- The allocation raises an error instead of dying. That is handled failure; check the error.
- A python kernel dies on large data. Same OOM family, but python-side tools apply.

## Steps
1. Confirm the kill: `dmesg | grep -i "killed process"` and note the kernel PID. Verify: the OOM killer is the cause.
2. Check the limits: `ulimit -v` and the container memory limit. Verify: you know the actual ceiling.
3. Find the allocation site: add logging around large mallocs or use a memory profiler for the language. Verify: you know which allocation crosses the line.
4. Restructure to bounded chunks or memory-mapped files instead of one giant allocation. Verify: peak RSS stays under the ceiling.
5. Re-run at full size. Verify: the kernel survives and the result is correct.

## Variant phrasings
### c kernel out of memory crash
Short form. Allocation pattern is the fix.

### native kernel dies large allocation
General phrasing. Chunk or memory-map.

### kernel killed allocating ram jupyter
Log-style phrasing. Check the OOM killer first.

Compatibility: Any native kernel (C, C++, Rust, Julia) under ipykernel-style protocol. OOM behavior is OS-level.

## Why it happens
Native kernels allocate directly with no managed heap to compact or collect, so a single allocation larger than available memory (or a slow leak across cells) ends with the OS killing the process. Python kernels at least have reference counting and gc to delay the inevitable; a C kernel that mallocs 64GB on a 16GB box dies immediately and silently.

## Edge cases / pitfalls
- Memory-mapped files still count against virtual memory limits under `ulimit -v`. Check virtual, not just resident, limits.
- Fragmentation can make a large contiguous allocation fail while total free memory looks fine. Chunking fixes this too.
- The OOM killer scores by memory use; a runaway sibling process can get your kernel killed. Check what else is on the box.
- Do not just raise the container limit without fixing the pattern. The next dataset will be bigger.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_o_OgJjsFNjBn0ZVbtX5xUA