Most Python exceptions come with a useful traceback, but a segmentation fault simply ends the process with a message like "Segmentation fault (core dumped)." When this happens, what debugging steps and tools do you normally use to find the cause?
4 Answers
Start by enabling Python’s built-in faulthandler. It can print the Python stack and often show which line was running when the interpreter crashed. Run Python with it enabled or add `import faulthandler; faulthandler.enable()` early in the program.
It’s also worth checking resource and environment problems. A process that runs out of memory can sometimes fail inside a native component, so monitor memory usage and try a memory diagnostic such as memtest if the crash is widespread or happens in unrelated programs. System tracing tools like `strace` may provide additional clues about what the process was doing immediately before it died.
Python itself normally protects you from direct memory errors, so segmentation faults are more commonly caused by C extensions, compiled dependencies, or native libraries such as numerical, graphics, or vendor-specific packages. Check recently added dependencies, try reproducing the crash in a smaller script, and update or isolate the library that triggers it.
If faulthandler points toward an extension or doesn’t give enough information, move on to native debugging tools. GDB can show the C-level stack and help identify the failing library or function. Valgrind is also useful for invalid reads, writes, use-after-free bugs, and memory leaks, although it can make programs run much more slowly.
So the usual order is faulthandler first, then GDB or Valgrind if the crash appears to come from native code?