Skip to content

Tell HN: Gemini 3 found a stack smash in a hex dump that I missed

8 pointsleo_ediscuss
On HN

I spent the morning chasing a crash in our distributed engine. The stack trace pointed to a segfault deep inside folly::FiberManager.

gdb showed that a critical pointer was garbage: 0x676974736e6f5373.

Usually, I’d suspect a race condition or a use-after-free. I stared at the hex for a while, checking for alignment issues or bit-flips, but it just looked like random entropy.

Out of frustration, I pasted the info locals dump into Gemini 3. I didn't ask it to fix the code, I just asked: "What do you see?"

It didn't try to analyze the C++ logic. Instead, it treated the address as data. It pointed out that on an x86-64 (Little Endian) system, 0x676974736e6f5373 decodes perfectly to the ASCII string: "sSonstig".

It clicked immediately. "Sonstig" is German for "Miscellaneous".

It turns out a legacy localization function was writing the category name "Sonstiges" into a stack buffer that was too small. It overflowed and perfectly overwrote the FiberManager pointer with the bytes of the word.

I think we often focus too much on LLMs for "Code Generation" (writing boilerplate). For me, the real killer feature is Pattern Recognition in raw data. I would have stared at that hex for hours seeing only noise; the model recognized the semantic meaning in milliseconds.

Has anyone else found LLMs useful specifically for decoding raw dumps or logs like this?

Comments

No comments yet.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.