Stack Overflow — Not the Website, But the Error. Do You Really Know What It Means?

Most developers have seen the “Stack Overflow” error at some point in their career. But beyond the name, do we really understand what is happening under the hood?

Let’s break it down in a simple and practical way.

JavaScript Execution and Memory

When JavaScript runs in your browser (or Node.js), it executes programs in memory and consumes hardware resources. To manage this efficiently, JavaScript uses different memory regions to store data.

Broadly, JavaScript data types are divided into Primitive Types and Reference Types, and they are stored differently in memory.

Primitive Types (Stored in the Stack)

Primitive types include:

• Boolean
• Number
• String
• Null
• Undefined
• Symbol
• BigInt

These values are usually stored in a memory region called the Stack. The stack is fast and organized using a Last-In-First-Out (LIFO) structure.

Example:

let a = 10;
let b = a;

b = 20;

console.log(a); // 10
console.log(b); // 20
        

Here, b gets a copy of a. Each variable stores its own value in the stack.

Reference Types (Stored in the Heap)

Reference types include:

• Objects
• Arrays
• Functions
• Classes
• Maps / Sets

These are stored in another memory region called the Heap, which is used for dynamic and larger memory allocations.

Instead of storing the actual data in the stack, JavaScript stores a reference (memory address) pointing to the heap.

Example:

const arr1 = [1, 2, 3];
const arr2 = arr1;

arr2.push(4);

console.log(arr1); // [1, 2, 3, 4]
        

Here, arr1 and arr2 both point to the same memory location. Copying a reference does not create a new object.

To create a shallow copy, we can use:

const arr2 = [...arr1];
// or
const obj2 = Object.assign({}, obj1);
        

What Actually Causes a Stack Overflow?

The stack has a limited size per execution thread (often around ~1MB depending on the environment). Every time a function is called, it is added to the call stack.

If functions keep calling themselves indefinitely (or too deeply), the stack eventually fills up and cannot accept new entries. That is when JavaScript throws a Stack Overflow error.

Example:

function recursiveCall() {
  recursiveCall();
}

recursiveCall();
        

This infinite recursion fills the call stack and results in a stack overflow.

How React Helps Avoid Stack Overflow

React internally uses an architecture called React Fiber, which implements an incremental and iterative reconciliation process. Instead of relying heavily on deep recursion, React Fiber allows rendering work to be broken into smaller chunks. This helps prevent blocking the call stack and improves performance.

Memory Leaks in React (Heap Related)

While stack overflow relates to call stack limits, another common issue is memory leaks, which usually occur in heap memory.

A memory leak happens when memory is allocated but never released. JavaScript uses Garbage Collection (GC) to automatically clean unused memory. However, if references still exist, the garbage collector cannot remove that memory.

In React, this can happen when background processes continue running even after a component is unmounted.

Example of a potential memory leak:

useEffect(() => {
  const timer = setInterval(() => {
    console.log("Running...");
  }, 1000);
}, []);
        

If the component unmounts, the interval still runs, keeping memory alive.

Correct approach with cleanup:

useEffect(() => {
  const timer = setInterval(() => {
    console.log("Running...");
  }, 1000);

  return () => {
    clearInterval(timer);
  };
}, []);
        

The return function inside useEffect allows React to clean up resources and prevent memory leaks.

Key Takeaways

Primitive values are stored directly in the stack

Reference types store data in the heap and keep references in the stack

Stack Overflow occurs when the call stack exceeds its size limit (often due to deep recursion)

Memory leaks occur when references prevent garbage collection

React’s Fiber architecture helps reduce stack-related issues

Proper cleanup in useEffect helps prevent memory leaks

Understanding memory behavior is not just theoretical knowledge — it directly impacts application performance, scalability, and reliability. As developers, having this awareness helps us write safer and more efficient code.

What was your first experience debugging a stack overflow or memory leak? I’d love to hear your thoughts and experiences.