Not the website. The crash. The one where your program is humming along and then dies instantly with no useful error, or on Windows, EXCEPTION_STACK_OVERFLOW and status code 0xC00000FD. Usually it means a function called itself one too many times. Sometimes it means you asked the stack to hold something it was never sized for.

Here's what a stack overflow actually is, why it's sneaky, and how to find the runaway code responsible.

What the stack is, briefly

Every thread gets a chunk of memory called the stack, and it's where your program keeps the bookkeeping for function calls: local variables, return addresses, saved registers. Each time you call a function, a new frame goes on top. Each time a function returns, its frame comes off. The whole thing is fast and automatic, and it works beautifully right up until it's full.

The stack is also small. On Windows the default thread stack is one megabyte, which sounds like a lot until you put a few thousand function frames on it. When you push more onto the stack than it can hold, you get a stack overflow, and the program dies. There's no graceful recovery; the thing that would handle the error needs stack space too, and there isn't any.

Why it almost always means runaway recursion

The number one cause is infinite or unbounded recursion: a function that calls itself without a base case that actually stops it. Every call adds a frame, none of them return, and the stack fills in milliseconds.

The classic version is a missing or wrong base case. You meant to stop at zero and you're decrementing past it, or a condition that should terminate never goes true. The subtler version is mutual recursion, where function A calls B which calls A, and the cycle never closes. These are harder to spot because no single function looks recursive.

The less common but real cause is a genuinely enormous stack allocation: a huge fixed-size array declared as a local variable, for instance, that blows the budget in a single frame. Declaring a 2MB array on a 1MB stack is the programming equivalent of trying to parallel park a school bus. It is not going to fit, and everyone is going to watch you find out.

How to find where it overflowed

Here's what makes stack overflows uniquely annoying to diagnose: the stack trace is a mess by design. When the crash happens, the stack is full of thousands of copies of the same few frames, the exact recursive calls that filled it up. Some tools choke on that or truncate it.

But that repetition is also the diagnosis. A normal crash has a varied call stack. A stack overflow has the same handful of functions repeating over and over down the trace, hundreds or thousands deep. When you see processNode calling processNode calling processNode all the way down, you've found your culprit: that's the recursion with no brakes. The function that repeats is the function to fix.

So the move is to look at the deep, repeating portion of the stack and identify the cycle. Then find the base case that isn't firing, or the condition that never becomes true, and fix the thing that was supposed to make the recursion stop.

Why a native crash reporter helps

A stack overflow that happens on your machine is easy; your debugger catches it. The one that happens on a user's machine, triggered by an input depth or a data structure you never tested, is the one you need help with, and it's the one a crash reporter is built for.

BugSplat captures the crash from the field and symbolicates it, so the repeating frames come back as your actual function names instead of raw addresses, which is the difference between seeing the recursion and squinting at hex. It groups identical overflows together, so a recursion bug hitting many users shows up as one defect. And because it captures the crash where it happened, you find out about the input that triggered it without waiting for a user to figure out how to describe "it just closed."

If your application keeps its own log, you can attach that log right to the crash report in BugSplat, which for a recursion bug is genuinely useful: the log often shows the unusual input or state that sent the function spiraling, the context the stack trace alone can't give you. The stack tells you which function ran away. The log tells you what set it running.

The short version

A stack overflow means you filled the stack, almost always with runaway recursion. Find the function that repeats down the trace, fix the base case that never fires, and you're done. A symbolicated report turns that wall of repeated hex into a named function you can go fix, and an attached log tells you what triggered it.

Want to see how a native crash comes back symbolicated? You can start free and throw a test crash at it.