[PyQt] Help understanding a backtrace

[Phil Thompson]

On Thu, 19 Jan 2012 22:24:56 +0530, Kovid Goyal <kovid at kovidgoyal.net>
wrote:
> Hi all,
> 
> I've recently started getting random segfaults in calibre on my dev
machine
> (linux 64bit sip-4.13.1 and PyQt4-4.9). I compiled everything with -ggdb
> and
> generated the following backtrace from a core dump (Only kept the top 15
> calls)
> 
> #0  removeFromParent (self=0x5f66cc0) at siplib.c:5265
> #1  0x00007f6774aa4061 in sip_api_common_dtor (sipSelf=0x5f66cc0) at
> siplib.c:5183
> #2  0x00007f6774aa76d0 in add_object (om=<optimized out>,
addr=0x2f0e740,
> val=0x5ce39f0) at objmap.c:269
> #3  0x00007f6774aa7a6a in sipOMAddObject (om=0x7f6774caf980,
> val=0x5ce39f0) at objmap.c:163
> #4  0x00007f6774aa08bd in sipSimpleWrapper_init (self=0x5ce39f0,
> args=0x7f675403a150, kwds=0x0) at siplib.c:9149
> #5  0x00007f677c34b9f8 in type_call (type=<optimized out>,
> args=0x7f675403a150, kwds=0x0) at Objects/typeobject.c:737
> #6  0x00007f677c2f65d3 in PyObject_Call (func=0xba2c60, arg=<optimized
> out>, kw=<optimized out>) at Objects/abstract.c:2529
> #7  0x00007f6779ef9a08 in imap_next (lz=0x5ccfe50) at
>
/var/tmp/portage/dev-lang/python-2.7.2-r3/work/Python-2.7.2/Modules/itertoolsmodule.c:1549
> #8  0x00007f677c321b96 in listextend (self=0x5ccb368, b=<optimized out>)
> at Objects/listobject.c:872
> #9  0x00007f677c321e18 in list_init (self=0x5ccb368, args=<optimized
out>,
> kw=<optimized out>) at Objects/listobject.c:2458
> #10 0x00007f677c34b9f8 in type_call (type=<optimized out>,
> args=0x7f675403a750, kwds=0x0) at Objects/typeobject.c:737
> #11 0x00007f677c2f65d3 in PyObject_Call (func=0x7f677c6340e0,
> arg=<optimized out>, kw=<optimized out>) at Objects/abstract.c:2529
> #12 0x00007f677c38e23d in do_call (nk=<optimized out>, na=<optimized
out>,
> pp_stack=0x7fff9424b6e8, func=0x7f677c6340e0) at Python/ceval.c:4231
> #13 call_function (oparg=<optimized out>, pp_stack=0x7fff9424b6e8) at
> Python/ceval.c:4036
> #14 PyEval_EvalFrameEx (f=<optimized out>, throwflag=<optimized out>) at
> Python/ceval.c:2666
> ......<snipped some noise>
> #70 0x00007f677555948f in QMetaObject::activate (sender=0x6296e30,
> m=<optimized out>, local_signal_index=<optimized out>,
argv=0x7fff9424d5a0)
> at kernel/qobject.cpp:3278
> #71 0x00007f6773637b32 in QAction::triggered (this=<optimized out>,
> _t1=false) at .moc/release-shared/moc_qaction.cpp:263
> #72 0x00007f6773637d2a in QAction::activate (this=0x6296e30,
> event=<optimized out>) at kernel/qaction.cpp:1257
> #73 0x00007f67739dda6a in QAbstractButtonPrivate::click (this=0x62972e0)
> at widgets/qabstractbutton.cpp:528
> #74 0x00007f67739ddd1c in QAbstractButton::mouseReleaseEvent
> (this=0x6296c80, e=0x7fff9424e090) at widgets/qabstractbutton.cpp:1121
> #75 0x00007f6773a9a57a in QToolButton::mouseReleaseEvent
(this=<optimized
> out>, e=<optimized out>) at widgets/qtoolbutton.cpp:721
> 
> Now removeFromParent in siplib.c has
> 
> static void removeFromParent(sipWrapper *self)
> {
>     if (self->parent != NULL)
>     {
>         if (self->parent->first_child == self) <-- this is line 5265
>             self->parent->first_child = self->sibling_next;
> 
> I dont understand how this could segfault, unless the self->parent
> structure is
> corrupted. What circumstances could cause that to happen? Offhand I'd
> guess the
> parent is deleted in Qt, but that is just a guess. 
> 
> I'd appreciate some insight from someone more familiar with sip/PyQt.
I'll
> be
> happy to provide more information, if needed. The segfaults are rare and
> seem
> to occur at random times. Note that I have disabled cyclic garbage for
> python
> in calibre and run the garbage collection only in the GUI thread,
> manually, at
> fixed intervals. From the backtrace this particular crash appears to
> be happening in response to a click event, so the garbage collector
doesn't
> seem to be involved.

The current version of SIP made some changes to the the mapping between
Python and C++ objects. It might be worth trying a version without those
changes. You would need to backout the changes up to and including...

http://www.riverbankcomputing.com/hg/sip/rev/da88157d2f03

Phil