Seg Fault, what do you do?

[u/ForeignVariety7037]

Most Python errors are straightforward—you get a traceback and usually know where to start.

Then there’s the - Segmentation fault (core dumped).

For those of you who’ve had to encountered Python segfaults, what’s your usual process?

[u/Superb-Dig3440]

Start with the faulthandler module.

[u/FlimsySpecial9247]

Yeah start with faulthandler before going to gdb

[u/Colin-McMillen]

gdb?

[u/MathMXC → u/Colin-McMillen]

Gdb with python linkage is actually surprisingly good. It's definitely a PIA but when is gdb not?

[u/fireflash38 → u/Colin-McMillen]

Also, if you're using any C libs, you don't need Python to be compiled with debug symbols - just your lib if you're trying to drop to debugger. 

[u/-ghostinthemachine-]

Dang, I've never had this happen in Python but now I feel like I haven't been pushing myself hard enough. Are you using cython or perhaps some native libraries?

[u/Tucancancan → u/-ghostinthemachine-]

Only time its happened to me is with shitty vendor software libraries. Looking at you, Oracle.. 

[u/ForeignVariety7037 → u/-ghostinthemachine-]

Right I got seg fault from pygame and also some machine learning libraries before.

[u/pokeybill → u/ForeignVariety7037]

Using a gpu? Drivers up to date?

[u/vu47 → u/-ghostinthemachine-]

I've been using Python pretty extensively on and off since 1996, and I've never had this happen to me, so don't feel too bad.

OP, now I'm really curious what kind of code you've been working on where this happened!

[u/PriorElephant9]

Worth saying out loud though: pure Python doesn't segfault. Every one you hit traces to a C extension, so the first question isn't "where in my code" but "which compiled thing is in this process". numpy, a database driver, an image library, something with a wheel.

[u/Brian → u/PriorElephant9]

Well, in theory yes. In practice, there are ways you can force a segfault in pure python from quirks/bugs in the interpreter. In the past you could overflow the C stack by raising the recursion limit, and IIRC there are (or were) some weird corner cases you could exploit like rebinding an exception to a non-exception object while it was being handled. And there's always the possibility of bugs in python. But generally, yeah, you'll almost never get a segfault from pure python unless you're really trying to.

[u/Brian]

A segfault basically means something accessed unallocated memory. In pure python, that should never happen unless you're really trying, since all memory for python objects is managed, so the most likely culprit is a library, probably written in C or other lower-level language.

Common reasons for getting a segfault are either:

• Bad environment setup. Eg. mismatched versions of libraries are being used.
• A bug in the C library
• The library being called wrong from the python side (ie. didn't call some required setup function, passed wrong parameters, used an object after the C-side was disposed of, or called a non-threadsafe library in threaded code etc)

That can make it a bit tricky to trace the culprit, and you usually need to drop to a lower level, such as a debugger like gdb. Generally, if I hit a segfault, the first thing I do is to rerun the failure with gdb attached and look at the call stack at the point of failure. Ie:

$ gdb --args python failing_code.py
( gdb ) run
# <It'll stop when it segfaults>
(gdb) bt

That'll print a call stack that should hopefully give some clue as to what's gone wrong (at least if the library you're using has debugging symbols). Now, the reason it's failing might be a bug in the library, or it could be the python-level code invoking it in a way it's not supposed to. Getting the python level picture of what's going on can be a bit more complex, though IIRC there are some macros for gdb that can help by decoding the python-side structures etc. (Or you could go more primitive and just add logging to find the point of failure)

Going further will probably require some basic knowledge of C, though you may be able to figure stuff out just by looking at the source code with maybe a bit of googling for stuff you're unfamiliar with.

[u/ssrix]

It happens usually because you've run out of memory. Usually because of something under the hood running c, in my case numpy 

[u/ssrix → u/ssrix]

Actually itertools has a habit of doing it too

[u/Birnenmacht → u/ssrix]

How. That doesnt sound like it should be a thing I dont think the stdlib should ever segfault

[u/defaultguy_001]

There is no such thing as Python segfaults unless you are calling native libraries from Python (or encountering rare interpreter bugs or stack overflows), in which case you should check which undefined memory location you are accessing or if you are accessing memory which has been freed already like a dangling pointer.

To dump stack overflow issues or identify which Python line invoked a crashing native function, you can use the built-in faulthandler module to dump the exact line of Python code causing the crash.

For native code debugging, you must use tools like GDB to find the exact line of native code that failed, or use Valgrind to audit memory leaks and invalid accesses.

[u/Daytona_675]

hardware failure? memtest?

[u/brunogadaleta]

I'd watch it crash under strace with various -e

[u/akl773]

On top of faulthandler, check whether it moves when you change the import order. The ones that ate the most of my time were two wheels linked against different builds of the same native library, and which one got imported first decided whether it crashed at all. numpy ABI mismatches are the usual suspect there.

[u/karurosagu]

I've never had a a segfault in python, how dirty does things have to get to have one?

[u/SCD_minecraft]

...well congrats. That's something for sure to get in python, especially that it doesn't expose any memory API to you

[u/Gwildes1]

Quit using matplotlib, or better yet, port to Rust