I'll see if I can come up with a minimal test to reproduce it. Right now it's happening in the context of a fairly large system.
On Sun, Jul 10, 2011 at 12:25 PM, Phil Thompson <[email protected] > wrote: > On Thu, 7 Jul 2011 14:27:25 -0500, 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? > > If the mro is NULL then something is wrong. > > Do you have a test that reproduces the problem? > > Phil > -- Paul Bonser | http://probablyprogramming.com | @pib
_______________________________________________ PyQt mailing list [email protected] http://www.riverbankcomputing.com/mailman/listinfo/pyqt
