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