Why Your Python Profiler Shows [unknown]: The Frame Pointer Chain Problem

Apr 16, 2026

I was debugging a performance issue in a Python application last week, and the profiler output stopped me cold. Half the stack traces showed [unknown] symbols instead of meaningful function names. I had frame pointers enabled in my Python build, my C compiler flags were correct, and I was using a modern profiler. What went wrong?

The answer: one C extension in my dependency chain was compiled without frame pointers, and that single missing link broke the entire stack unwinding process.

The Weakest Link Problem

A frame pointer chain works like a linked list through your call stack. Each function call stores a pointer to the previous stack frame, creating a chain that profilers can follow from the current instruction all the way back to main(). When everything works correctly, you get a complete view of your program’s execution path.

But here’s the critical insight: this chain is only as strong as its weakest link. If ANY compiled component in your call stack omits frame pointers, the chain breaks at that point, and profilers cannot continue past it.

┌─────────────────────────────────────────────────────────┐
│                    Call Stack Chain                      │
├─────────────────────────────────────────────────────────┤
│                                                          │
│  Python Code ──► CPython ──► numpy ──► libc              │
│       │             │           │        │               │
│       │             │           │        │               │
│       ▼             ▼           ▼        ▼               │
│   [known]       [known]     [known]  [known]             │
│                                                          │
├─────────────────────────────────────────────────────────┤
│          Scenario: numpy WITHOUT frame pointers           │
├─────────────────────────────────────────────────────────┤
│                                                          │
│  Python Code ──► CPython ──► numpy ──► ??? ──► ???       │
│       │             │           │       │       │        │
│       │             │           │       │       │        │
│       ▼             ▼           ▼       ▼       ▼        │
│   [known]       [known]     [known] [unknown] [unknown]  │
│                               ╱╲                         │
│                              ╱  ╲                        │
│                             ╱    ╲                       │
│                       CHAIN BREAKS                       │
│                       HERE                               │
│                                                          │
└─────────────────────────────────────────────────────────┘

I saw this firsthand when profiling a data processing pipeline. The stack trace looked like this:

#0  0x00007f8b2c301234 in __libc_start_main
#1  0x00007f8b2d450678 in Py_BytesMain
#2  0x00007f8b2d789abc in PyObject_Call
#3  0x00007f8b2e123456 in numpy.core._multiarray_umath
#4  0x00007f8b2e789def in [unknown]
#5  0x00007f8b2e890123 in [unknown]
#6  0x00007f8b2e9ab456 in [unknown]

The profiler successfully traced from libc through CPython and into the numpy extension, but then hit a wall. Numpy was compiled without frame pointers, so the unwinder couldn’t follow the chain any further. All those [unknown] frames could have been valuable debugging information—my actual business logic, helper functions, or the root cause of the performance issue.

Why This Happens

Frame pointers require CPU registers and stack space to maintain. On x86-64, the %rbp register holds the frame pointer for each function. The overhead is small (typically 1-3% performance impact), but measurable. Many build systems default to -fomit-frame-pointer for this reason, trading debuggability for raw speed.

When Python 3.12 added perf trampoline support, it addressed part of the problem. The trampoline helps profilers understand Python-level call frames. But as one Reddit commenter pointed out, this solution remains incomplete without frame pointers in native code—you get Python frames but still miss native frames in the call stack.

Most performance-sensitive Python code already uses C extensions or Rust extensions where the frame pointer overhead becomes negligible compared to the actual work being done. The real problem is that these extensions often get built with default compiler flags that omit frame pointers.

PEP 831: The Propagation Solution

PEP 831 introduces a mechanism to propagate frame pointer compiler flags from Python to its C extensions. When you build Python with frame pointers enabled, Python’s sysconfig module exposes the appropriate compiler flags (-fno-omit-frame-pointer on most platforms). C extensions built with pip install will automatically inherit these flags.

This is a significant improvement because it ensures consistency within the CPython ecosystem. You enable frame pointers once, and the flag propagates to all standard C extensions.

But here’s the catch: PEP 831 only affects extensions that actually query sysconfig for their build flags. Third-party packages that hardcode their own compiler settings, use custom build systems, or distribute pre-built wheels may still end up without frame pointers.

I learned this the hard way when a performance-critical package I depended on distributed binary wheels compiled with -O3 -fomit-frame-pointer. My entire profiling session was useless because that one package broke the chain.

Checking Your Extensions

You can verify whether your C extensions have frame pointers enabled using a few different methods.

First, check the build logs if you compile from source. Look for -fno-omit-frame-pointer in the compiler invocations.

Second, use objdump to inspect the compiled binary. Frame pointer usage creates a distinctive prologue pattern at the start of functions:

# Look for the frame pointer setup pattern
objdump -d my_extension.so | grep -A1 "push.*%rbp"

# If frame pointers are enabled, you'll see:
#   push %rbp
#   mov  %rsp,%rbp

Third, use readelf to check for DWARF debug information, which often correlates with frame pointer preservation:

readelf -S my_extension.so | grep debug

# Sections like .debug_info, .debug_frame suggest better debugging support

If your extension lacks these indicators, you’ll need to rebuild it with frame pointers enabled.

Building with Frame Pointers

For packages you control, ensure your setup.py or pyproject.toml respects the sysconfig flags. The standard setuptools build process does this automatically when you use the provided compiler configuration.

For third-party packages, rebuild from source with the correct flags:

# This forces compilation from source and uses sysconfig flags
pip install --no-binary :all: numpy

# Verify the build used frame pointers
python -c "import numpy; print(numpy.__file__)"
# Then check with objdump as shown above

The --no-binary :all: flag tells pip to ignore pre-built wheels and compile everything from source. This ensures the build uses your system’s Python configuration, including the frame pointer flags from sysconfig.

For packages with complex build systems like PyTorch or TensorFlow, you may need to set environment variables explicitly:

export CFLAGS="-fno-omit-frame-pointer $CFLAGS"
export CXXFLAGS="-fno-omit-frame-pointer $CXXFLAGS"
pip install --no-binary :all: torch

When to Accept the Gap

Not every library needs frame pointers. Pure Python code doesn’t need them at all—CPython’s internal frame management handles stack unwinding for Python-level calls. The issue only surfaces at the boundary between Python and native code.

If you’re profiling a script that spends 99% of its time in one C extension, and you only need to optimize that extension, the broken chain beyond it might not matter. Your profiler shows you exactly where the time goes—inside that extension—and you can investigate further with specialized tools like perf record -g or vendor-specific profilers.

But for complex applications with multiple native extensions calling each other, the complete call graph becomes essential. You can’t optimize what you can’t see.

Practical Workflow

I’ve adopted a systematic approach to ensure profiling works end-to-end:

Check Python build: Verify my Python installation has frame pointers enabled
Audit dependencies: Identify which packages have C extensions
Rebuild critical paths: Compile performance-critical packages from source
Verify with test profile: Run a quick profiling session to confirm complete stacks

# Check if Python itself was built with frame pointers
python -c "import sysconfig; print(sysconfig.get_config_var('CFLAGS'))"

# Look for -fno-omit-frame-pointer in the output

This verification step prevents the frustrating discovery of broken chains mid-debugging session.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

👨‍💻 PEP 831

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!