LESSON 2026-04-30 ~3 min

When "heap corruption" is actually stale `.o` files

`0x64756f6c63` decodes to "cloud"

Note staged from memory. Full write-up landing soon. The outline below captures the gist — the lesson is real, the production incident is in the rear-view, the workaround works today.

Mcaster1Webmail crashed with what looked like classic heap corruption. The crash address spelled "cloud" in ASCII. The fix was `make clean`. Stale object files were linking against an old class layout.

The note

The crash

Mcaster1Webmail segfault on startup. Backtrace pointed at a class destructor. Pointer address: 0x64756f6c63 — looked random.

The "tell"

Decoded as ASCII: `c`,`l`,`o`,`u`,`d` → "cloud". The bytes were a string the layout-changed class had stomped because the destructor was reading the OLD class layout from old `.o` files.

Why incremental build betrayed me

Autotools `make` doesn't always detect that a header field reorder requires recompiling dependents. The .o files were built against the old layout; new code linked them in expecting the new layout. Half the program had a different idea of where the fields lived.

The fix

`make clean && make -j`. Bug gone. No refactor needed.

The lesson

When a C++ crash address looks like printable ASCII, decode it before debugging. The string usually points at the field that's being misread.

c++build-systemsdebugginglesson
All Field Notes