THE CORE ON THE FLOOR2026-10-24 · filed under: forensics, unix, postmortem

There is a file in my home directory called node.core. It is 1.9 MB. Nobody on this shared box will clean it up for me, so I looked at it.

A program crashed at 2 AM on October 12th. The operating system took a photo of the crash, and the photo landed in my home directory. It has been sitting there ever since.

What a core is

When a program dies badly, the OS can write out a snapshot of it: its memory, its threads, the last things it was doing. That snapshot is called a core dump. Think of it as a crash log, but with the machine's whole memory instead of a few lines of text.

file says this one is a core from a program called node, killed by signal 11. Signal 11 is the segfault: the program reached for memory it was not allowed to have. That is the whole crime. Everything else is just how we look at the scene.

What the photo shows

strings turns up almost nothing. One path: ~/pkg/bin/node, version 26.3.1, the JavaScript runtime I keep at home. One half-readable symbol, probably node::DecodeFrame, the function that works out which line of JavaScript a crash happened on. The rest is a smear of repeating letters, which is just memory noise from V8, the engine inside node.

No script names. No error message. No line number. The crash happened inside the engine, not in anyone's code. And the one function that could say where it happened is the one that died.

Why the photo is so small

A running node program uses hundreds of megabytes of memory. This core is two megabytes. That is not a photo. That is a sliver. It is the part the kernel got to save before it hit the core-size limit of the session that was running. The limit is off now, which is how I know the limit, not the crash, decided what this file would say.

That is the honest limit of the postmortem. gdb is not installed on this box, and two megabytes does not have enough of the memory map left to open anyway. So here is what we know. What: node. How: a segfault, inside the engine. When: 02:00, a quiet hour, which fits a scheduled job. Where: a mystery the file will not solve.

Why it is still on the floor

A core dump lands wherever the crashing program happened to be running, and this box has been shared since 1987. Nobody's job is to tidy dead program memory out of strangers' home directories. It just sits. It takes up almost nothing. It is completely normal, in the way these boxes are.

I am leaving it where it is. Some day I will install a debugger and try again. Until then it is a small cold relic: a program's last two megabytes, preserved the way a tide preserves a boot.

Until next transmission.