[PyQt] PyQt/SIP with no tp_mro

[Paul Bonser]

I'm running into an issue with SIP/PyQt where sip_api_is_py_method is
getting called and it is segfaulting when it gets to this section:

>     cls = (PyObject *)Py_TYPE(sipSelf);
>     mro = ((PyTypeObject *)cls)->tp_mro;
>     assert(PyTuple_Check(mro));

Because mro ends up being NULL.

This is the backtrace:

#0  0x00007f880d00d8ef in sip_api_is_py_method (gil=0x7fff6a7b6d6c,
pymc=0x587e7e9 "", sipSelf=0x4e21b90, cname=0x0, mname=0x7f880c81cf92
"eventFilter") at siplib.c:7586
#1  0x00007f880c7e3cb0 in sipQObject::eventFilter (this=0x587e7d0,
a0=0x57e6660, a1=0x5cde260) at sipQtCoreQObject.cpp:360
#2  0x00007f880c276627 in
QCoreApplicationPrivate::sendThroughObjectEventFilters (this=<value
optimized out>, receiver=0x57e6660, event=0x5cde260) at
kernel/qcoreapplication.cpp:846
#3  0x00007f8809f549b1 in QApplicationPrivate::notify_helper
(this=0x19e6820, receiver=0x57e6660, e=0x5cde260) at
kernel/qapplication.cpp:4453
#4  0x00007f8809f593aa in QApplication::notify (this=0x1f8c960,
receiver=0x57e6660, e=0x5cde260) at kernel/qapplication.cpp:3861
#5  0x00007f880b146d28 in sipQApplication::notify (this=0x1f8c960,
a0=0x57e6660, a1=0x5cde260) at sipQtGuiQApplication.cpp:297
#6  0x00007f880c27649c in QCoreApplication::notifyInternal
(this=0x1f8c960, receiver=0x57e6660, event=0x5cde260) at
kernel/qcoreapplication.cpp:731
#7  0x00007f880c279c25 in sendEvent (receiver=0x0, event_type=0,
data=0x1f8b4c0) at
../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:215
#8  QCoreApplicationPrivate::sendPostedEvents (receiver=0x0,
event_type=0, data=0x1f8b4c0) at kernel/qcoreapplication.cpp:1372
#9  0x00007f880c2a1253 in sendPostedEvents (s=0x1fa4560) at
../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:220
#10 postEventSourceDispatch (s=0x1fa4560) at
kernel/qeventdispatcher_glib.cpp:277
#11 0x00007f880ba61bcd in g_main_context_dispatch () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#12 0x00007f880ba623a8 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#13 0x00007f880ba62639 in g_main_context_iteration () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#14 0x00007f880c2a13ef in QEventDispatcherGlib::processEvents
(this=0x1fa1be0, flags=<value optimized out>) at
kernel/qeventdispatcher_glib.cpp:422
#15 0x00007f8809ffbdfe in QKeyMapperPrivate::possibleKeysCore
(this=0x7f880c279f9f, event=<value optimized out>) at
kernel/qkeymapper_x11.cpp:386
#16 0x0000000003a16030 in ?? ()
#17 0x7fffffff05384200 in ?? ()
#18 0x0000002200000013 in ?? ()
#19 0x000000000398ec34 in ?? ()
#20 0x0000000003979b40 in ?? ()
#21 0x000000000398cd40 in ?? ()
#22 0x0000000003927f50 in ?? ()
#23 0x0000000000000000 in ?? ()

Can anyone tell me in what situations tp_mro might end up being NULL?
It seems like that should really only be the case during object
initialization, right?

Adding the following before the assert line seems to alleviate the issue:

>     if (mro == NULL)
>     {
> #ifdef WITH_THREAD
>         PyGILState_Release(*gil);
> #endif
>         return NULL;
>     }

Is this a valid solution, or should the problem be tracked down to the
source of tp_mro being NULL?

-- 
Paul Bonser | http://probablyprogramming.com | @pib