Track down SIGABRT

[dieter]

Israel Brewster <israel at ravnalaska.net> writes:
> ...
> Running it through GDB didn't seem to give me much more information than that crash report - I can see that it is in thread 0, and the call stack is identical to what the crash report shows, but I can't see where in the python code it is.
> ...
> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
> 0   libsystem_kernel.dylib        	0x98176be6 __select + 10
> 1   time.so                       	0x0052fdda 0x52f000 + 3546
> 2   org.python.python             	0x0007e90a PyCFunction_Call + 98
> 3   org.python.python             	0x000ccef4 PyEval_EvalFrameEx + 8182
> 4   org.python.python             	0x000caeb2 PyEval_EvalCodeEx + 1777

This tells you: the crash happens somewhere in a call to a function
defined in "time.so".
I suppose that all such functions are harmless in themselves.


I see two potential causes:

  *  a stack overflow
     some Python builds are made with quite a small thread runtime stack.
     However, you would usually get a "SIGSEGV" rather than
     a "SIGABRT".

  *  a bad pointer passed in to the function.
     Again, I would expect rather a "SIGSEGV" than a "SIGABRT" --
     but maybe "__select" has a special sanity check for its arguments
     and raises "SIGABRT" when the check fails.

In order to determine where in your Python code the problem happens,
you likely need a Python with debugging symbols (system installed
Python interpreters usually are "stripped", e.g. they no longer
have debugging symbols).

Python comes with GDB macros able to show you information
at the Python (rather than the C) level. Here (Ubuntu 12.4),
it is at "/usr/share/doc/python2.7/gdbinit.gz".
Those macros need debugging symbols.
Read the top of this file, for how to get those macros defined
in your GDB session.


I doubt that being able to relate the problem to code
at the Python level will help you much. Your "SIGABRT" problem
is likely not caused on the Python level (but at C level).

If it is not caused by a runtime stack overflow, the cause is likely
a memory corruption, made non locally (far away) in some C extension.
Using a tool to track down memory corruption might help you
(however, in my experience, it is usually a huge task).