Native crash frames generated by Cython-compiled code appear as mangled C
symbols (e.g. __pyx_pw_6module_3func) in sentry-native stack traces, making
them unreadable without manual demangling. The Python SDK captures Cython
frames correctly at the Python level (.pyx file, line number), but when a
crash occurs in the native layer of a Cython extension, the native stack frames
shown in Sentry are opaque.
Current behavior
- Python-level Cython frames (captured by sentry-python via
sys.exc_info())
show correct .pyx source file and line number
- Native frames from the C code generated by Cython (captured by sentry-native
on crash) show raw mangled symbols: __pyx_pw_6module_3func_1name,
__pyx_f_6module_3ClassName_method, etc.
- C++ demangling (
__cxa_demangle) does not apply to Cython's naming scheme
- No Cython-specific demangling exists in sentry-python or the Sentry backend
Gap
Cython uses a deterministic, documented symbol naming convention for the C code
it generates. A demangler can reconstruct the original Python-facing name from
a __pyx_* symbol:
__pyx_pw_<module>_<n><name> → Python wrapper for <module>.<name>__pyx_f_<module>_<ClassName>_<method> → C-level function for
<module>.<ClassName>.<method>
This demangling could be applied as a post-processing step in the
GnuBacktraceIntegration or as a standalone CythonIntegration, enriching
native frames with human-readable Cython source names before the event is sent
to Sentry.
Options
- Extend
GnuBacktraceIntegration to detect and demangle __pyx_* symbols
in parsed backtrace frames — lowest friction, reuses existing pipeline
- Add a standalone
CythonIntegration event processor that post-processes
all native frames across exception and crash events — cleaner separation,
applicable beyond GnuBacktrace-formatted strings
- Implement server-side demangling in the Sentry symbolicator for
__pyx_*
symbols — transparent to SDK users, but requires changes outside this repo
References
Action taken on behalf of Angelo de Voer.
Native crash frames generated by Cython-compiled code appear as mangled C
symbols (e.g.
__pyx_pw_6module_3func) in sentry-native stack traces, makingthem unreadable without manual demangling. The Python SDK captures Cython
frames correctly at the Python level (
.pyxfile, line number), but when acrash occurs in the native layer of a Cython extension, the native stack frames
shown in Sentry are opaque.
Current behavior
sys.exc_info())show correct
.pyxsource file and line numberon crash) show raw mangled symbols:
__pyx_pw_6module_3func_1name,__pyx_f_6module_3ClassName_method, etc.__cxa_demangle) does not apply to Cython's naming schemeGap
Cython uses a deterministic, documented symbol naming convention for the C code
it generates. A demangler can reconstruct the original Python-facing name from
a
__pyx_*symbol:__pyx_pw_<module>_<n><name>→ Python wrapper for<module>.<name>__pyx_f_<module>_<ClassName>_<method>→ C-level function for<module>.<ClassName>.<method>This demangling could be applied as a post-processing step in the
GnuBacktraceIntegrationor as a standaloneCythonIntegration, enrichingnative frames with human-readable Cython source names before the event is sent
to Sentry.
Options
GnuBacktraceIntegrationto detect and demangle__pyx_*symbolsin parsed backtrace frames — lowest friction, reuses existing pipeline
CythonIntegrationevent processor that post-processesall native frames across exception and crash events — cleaner separation,
applicable beyond
GnuBacktrace-formatted strings__pyx_*symbols — transparent to SDK users, but requires changes outside this repo
References
GnuBacktraceIntegration:sentry_sdk/integrations/gnu_backtrace.pyAction taken on behalf of Angelo de Voer.