SIGSEGV and SIGILL inside PyCFunction_Call
Anders Wegge Keller
wegge at wegge.dk
Wed Jul 19 11:35:28 EDT 2017
I have an ongoing issue with my usenet setup. I'm that one dude who don't
want to learn perl. That means that I have to build inn from source, so I
can enable the python interpreter. That's not so bad, and the errors that
show up have been something that I have been able to figure out by myself.
At least up until now. I have an almost 100% repeatable crash, when nnrpd
performs the user authentication step. Backtracing the core dum gives this:
#0 0x0000564a864e2d63 in ?? ()
#1 0x00007f9609567091 in call_function (oparg=<optimized out>,
pp_stack=0x7ffda2d801b0) at ../Python/ceval.c:4352
Note: Line 4352 C_TRACE(x, PyCFunction_Call(func,callargs,NULL));
#2 PyEval_EvalFrameEx (
f=Frame 0x7f9604758050, for file /etc/news/filter/nnrpd_auth.py,
line 67, in __init__ (self=<AUTH(dbCursor=<Cursor(_result=None,
description=None, rownumber=None, messages=[], _executed=None,
...
Weird observation #1: Sometimes the reason is SIGSEGV, sometimes it's
SIGILL.
Weird observation #2: After typically a few hundred failures, a nnrpd
instance is born under some very lucky stars, after which it survives any
attempt at user authentication.
I'm not ready to give up yet, but I need some help proceeding from here.
What do the C_TRACE really do, and is there some way of getting a level
deeper, to see what cause the SEGV. Also, how can the C code end up with an
illegal instruction_
--
//Wegge
More information about the Python-list
mailing list