What causes a Python segmentation fault?

I am implementing Kosaraju's Strong Connected Component(SCC) graph search algorithm in Python.

The program runs great on small data set, but when I run it on a super-large graph (more than 800,000 nodes), it says "Segmentation Fault".

What might be the cause of it? Thank you!

Additional Info: First I got this Error when running on the super-large data set:

"RuntimeError: maximum recursion depth exceeded in cmp"

Then I reset the recursion limit using

sys.setrecursionlimit(50000)

but got a 'Segmentation fault'

Believe me it's not a infinite loop, it runs correct on relatively smaller data. It is possible the program exhausted the resources?

Solution 1:

This happens when a python extension (written in C) tries to access a memory beyond reach.

You can trace it in following ways.

• Add sys.settrace at the very first line of the code.

• Use gdb as described by Mark in this answer.. At the command prompt

  gdb python
  (gdb) run /path/to/script.py
  ## wait for segfault ##
  (gdb) backtrace
  ## stack trace of the c code
  

Solution 2:

I understand you've solved your issue, but for others reading this thread, here is the answer: you have to increase the stack that your operating system allocates for the python process.

The way to do it, is operating system dependant. In linux, you can check with the command ulimit -s your current value and you can increase it with ulimit -s <new_value>

Try doubling the previous value and continue doubling if it does not work, until you find one that does or run out of memory.

Solution 3:

Segmentation fault is a generic one, there are many possible reasons for this:

• Low memory
• Faulty Ram memory
• Fetching a huge data set from the db using a query (if the size of fetched data is more than swap mem)
• wrong query / buggy code
• having long loop (multiple recursion)

Solution 4:

Updating the ulimit worked for my Kosaraju's SCC implementation by fixing the segfault on both Python (Python segfault.. who knew!) and C++ implementations.

For my MAC, I found out the possible maximum via :

$ ulimit -s -H
65532