[PyQt] PyQt/SIP with no tp_mro

[Paul Bonser]

Oh, also, the event that was triggered was a DeferredDelete event, in
case it helps to know that.

On Thu, Jul 7, 2011 at 2:27 PM, Paul Bonser <misterpib at gmail.com> wrote:
> 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
>



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