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 <[email protected]> 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 _______________________________________________ PyQt mailing list [email protected] http://www.riverbankcomputing.com/mailman/listinfo/pyqt
