[PyQt] segfault using daily snapshot

[Erik Janssens]

Hello Phil

Thank you for your assistance. Yes, threads are involved
in my tests.  The segfault for sure happens during a
'deconstruction' phase, most of the time this is at the
end of the tests, but not always.

I don't think there is any recursive behavior involved,
our stress tests consist of generating a huge number of
Camelot form and table views one after another.

I tried to change the code as you suggested to :

static void clear_access_func(sipSimpleWrapper *sw)
{
    sipAccessFunc old_access_func;
    old_access_func = NULL;
    if (sw->access_func != NULL)
    {
       old_access_func = sw->access_func;
       sw->access_func = NULL;
    }
    if (old_access_func != NULL)
    {
       old_access_func(sw, ReleaseGuard);
    }
    sw->data = NULL;
}

maybe a bit too much code, but I wanted to be sure.

but it didn't help, still the same effect, I also tried
to put a SIP_BLOCK_THREADS around the code block, but it
didn't help either.

would it be possible that a single QObject has multiple
python wrappers, resulting in duplicate deletes ?

what is for sure is that when I comment out the ReleaseGuard
function, there are no segfaults.

what is the purpose of the ReleaseGuard step ?  I don't find
any docs on it in the qt docs.

Maybe I should give a bit more background on the issue.  We
have observed a number of segfaults with users of our application.
What is strange is that this number is far higher with
Windows 7 users.  Also, on Windows 7 the crashes seem more
severe (push-the-button-time).  As this is the only segfault
I'm able to produce with testing, I suspect it's this issue
causing the Windows 7 segfaults, but that's not sure of course.

What I could do is deploy a number of apps with the ReleaseGuard
line removed, to confirm this is the issue, but then I'd like
to understand what the line is about ?

Another option would be to deploy debug-builds on Windows, but
I'm really unfamiliar with doing such thing so I'd like to
avoid it.

Regards,

Erik


On Fri, 2010-12-17 at 18:47 +0000, Phil Thompson wrote:
> On Fri, 17 Dec 2010 09:17:14 +0100, Erik Janssens
> <Erik.Janssens at conceptive.be> wrote:
> > Hello Phil,
> > 
> > please find enclosed a stack trace with a debug build
> > of the last qt / pyqt releases.
> > 
> > apart from my stress-tests, I did not yet found an 
> > easy way to reproduce it.  but I'm quite sure it affects
> > our users as well during their daily use.
> > 
> > I do have a 60Mb core dump of it, but the whole debug
> > build is more than 700Mb.
> > 
> > Should you have any hints for me on how to investigate
> > this further...
> 
> Nothing looks obviously wrong.
> 
> Are threads involved in your tests?
> 
> Does the crash happen during normal execution, or only when the
> interpreter terminates?
> 
> SIP gets the address of a C++ instance via an access function. PyQt
> supplies qpointer_access_func() which uses a QPointer<QObject> so that it
> can detect when a QObject created internally by Qt gets deleted. (PyQt can
> detect when a QObject created by PyQt gets deleted by another mechanism.)
> The crash is happening when the resources used to implement the QPointer
> are being released when the Python object wrapping the C++ QObject is being
> garbage collected.
> 
> I will assume for the moment that QPointer works properly - although I'm
> not totally convinced as there seems to be a race condition in
> QMetaObject::removeGuard().
> 
> Looking at the implementation of clear_access_func() in siplib.c you can
> see that it tries to make sure that the resources are not freed twice by
> resetting the the pointer to the access function.
> 
> Unless there is something fairly obvious that I am missing (which is quite
> possible) I would start to suspect timing issues - although the stack trace
> doesn't suggest any recursive behaviour.
> 
> You might want to try changing clear_access_func() so that it saves the
> value of sw->access_func, clears it, then calls the access function using
> the saved pointer.
> 
> Phil