[PyQt] segfault using daily snapshot
Erik.Janssens at conceptive.be
Sat Dec 18 10:40:07 GMT 2010
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)
old_access_func = NULL;
if (sw->access_func != NULL)
old_access_func = sw->access_func;
sw->access_func = NULL;
if (old_access_func != NULL)
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
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
> 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.
More information about the PyQt