pythonqt
pythonqt copied to clipboard
MeVisLab
Segfault in PythonQtPrivate::createNewPythonQtInstanceWrapper
Dear PythonQt community,
I recent upgraded from the old trunk r502 (sourceforge) to latest code on GitHub master branch, committish 9ea0fcf of 2 December 2020. I did this in order to get compatibility with Python 3.8. Using Python 2.7 and 3.6 have both worked fine with "r502".
Now when I try to use the latest PythonQt with code which previously worked fine, I get a segmentation fault. Looking at some (somewhat) recent commits I see there has been some work going on in the area where the segfault happens. Though it's hard for me to identify which commit introduced the issue.
The backtrace is here:
#0 0x00007ffff40f403f in PyObject_Call () at /lib64/libpython2.7.so.1.0
#1 0x00007ffff3d11dc0 in PythonQtPrivate::createNewPythonQtInstanceWrapper(QObject*, PythonQtClassInfo*, void*) ()
at /home/xxx/git/qtbuild/libPythonQt-Qt5-Python2.7.so.3
#2 0x00007ffff3d13b11 in PythonQtPrivate::wrapPtr(void*, QByteArray const&, bool) () at /home/xxx/git/qtbuild/libPythonQt-Qt5-Python2.7.so.3
#3 0x00007ffff3db78c7 in PythonQtConv::createCopyFromMetaType(int, void const*) () at /home/xxx/git/qtbuild/libPythonQt-Qt5-Python2.7.so.3
#4 0x00007ffff3db8663 in PythonQtConv::QVariantListToPyObject(QList<QVariant> const&) () at /home/xxx/git/qtbuild/libPythonQt-Qt5-Python2.7.so.3
#5 0x00007ffff3dbc6b2 in PythonQtSignalTarget::call(_object*, PythonQtMethodInfo const*, void**, bool) ()
at /home/xxx/git/qtbuild/libPythonQt-Qt5-Python2.7.so.3
#6 0x00007ffff3dbc7eb in PythonQtSignalTarget::call(void**) const ()
at /home/xxx/git/qtbuild/libPythonQt-Qt5-Python2.7.so.3
#7 0x00007ffff3dbd04a in PythonQtSignalReceiver::qt_metacall(QMetaObject::Call, int, void**) () at /home/xxx/git/qtbuild/libPythonQt-Qt5-Python2.7.so.3
#8 0x00007fffef35a144 in QMetaObject::activate(QObject*, int, int, void**) ()
at /lib64/libQt5Core.so.5
I am using CentOS 7.9.2009 which has Python 2.7.5 and Qt 5.9.7.
I would very much appreciate the community's and the developers' insight. Thank you.
The stacktrace alone is insufficient to guess the cause of this crash, I'm afraid you need to look at the state of the used variables in a debugger to determine what went wrong, probably starting at frame 2 (since the PyObject_Call is the first thing done in createNewPythonQtInstanceWrapper). Probably an improper class "info" is found in that method (or none is found at all?) but the reason for this can only be found by debugging.
I will check in wrapPtr what the state of variables are. The scripting interface is working in many other places so its not a generic issue. This issue originates by a signal which is evident in the stacktrace as well so perhaps PythonQt became more strict (or does things differently now) and something in that QVariantList is missing a meta type declaration. I'll report back.
So the segfault happens on a bespoke data type but it has been declared with Q_DECLARE_METATYPE. It also works for the same data type on two previous calls and for another bespoke datatype which has been declared with Q_DECLARE_METATYPE. The difference between the three calls for this data type is that in the first call to wrapPtr for this data type wrap is null, info is not null after call to getClassInfo, a downcasting takes place as it is found is not a QObject, it is registered as a CPP class, a possible alive wrapper is not found and there is a call to createNewPythonQtInstanceWrapper which succeeds. The exactly same thing happens the second and third time except it is not registered as a CPP class in that call which would imply that info->pythonQtClassWrapper() returns non-NULL. In the third call for this data type it segfaults in the call to createNewPythonQtInstanceWrapper.
In call three calls to createNewPythonQtInstanceWrapper, wrapper argument is NULL, info argument is a pointer with the same address in each case, and ptr argument is a pointer with a different address in each case.
The bespoke data type is question is a struct and a member of a class. Hence it cannot be a QObject as Qt meta object compiler (moc) doesn't allowed nested QObject. It's not possible to declare a QObject class inside a QObject class. I also do not subclass QObject for these bespoke data types as I need to be able to copy them.
I also checked the return value of info->pythonQtClassWrapper() in createNewPythonQtInstanceWrapper and it returns the same pointer address for all three calls. On the third call for this data type it segfaults in the call to PyObject_Call.
So I have done a day of debugging and looking at the use of the the bespoke data type. I could not identify any internal issue in the struct attributes such as invalid or null QVariant between the three calls. I then tried disabling use of the data type and various callers and users of it. What I could reproduce is that the segfault always happens on the third call to wrapPtr for the data type. So to be that would seem to mean that the initial wrapping of it using the cpp wrapper works, and does the second call using of the already wrapped one, while the third call trying to use the already wrapped one fails.
I will try next and see what happens if I disable the caching of the wrapped data type.
This is just a hunch, but you could try to revert the changes done by Gregor Anich to fix some memory leaks and see if this helps. Perhaps one of the changes was a little bit to eager or requires further changes at another place.
That's quite a lot of changes. I will try and see if I can rebase without all his commits and see what happens. I rather have memory leaks than segfaults.
I did a rebase and removed the following commits:
pick 06860d4 Fix reference/memory leaks pick 525ea41 More potential leak fixes and build fix pick 295a9ce Stylistic changes and refcount fixes in PythonQtImporter_load_module pick 383fb8e Allow setting PYTHON_VERSION and PYTHON_DIR when including python.prf, add rpath pick 9ea0fcf Fix name clash with Visual Studio 2017
It now works fine. So the issue is probably too aggressive "garbage collection" so the a pointer to the CPP wrapper is accessed after being freed.
I would need to help of @gregor-anich-uibk to figure out what in all of his changes introduced this regression.
You could try to use valgrind to find out more about what's going on, if you could provide a short piece of code that triggers the error I can also look into it to see if your use-case is strange or if a bug in PythonQt needs to be fixed.
Well, my use case is that I use two CPP classes/structs which are declared as meta type with Q_DECLARE_METATYPE and have worked fine for the last three years using trunk-r502 and official releases before that, and now also work fine after removing the five commits listed above. My segfault only occurs for my two wrapped CPP objects and never for the thousands of wrapped QObject objects - so there is something fishy when dealing with CPP wrapped data types/classes which was introduced in one of the five above listed commits.
I don't think I can get funding to develop the short piece of code to reproduce this as the problem with Python 3.8 support is now resolved using the latest code with the five commits listed above removed and we probably can use the new baseline of PythonQt for the next 10 years until it is time for RHEL 9 or Ubuntu 30.04 LTS :-) Works fine now on CentOS 6.x (Python 2.6, Qt 5.6), CentOS 7.x (Python 2.7, Qt 5.9), CentOS 8.x (Python 3.6, Qt 5.12), and Ubuntu 20.04 LTS (Python 3.8, Qt 5.12).
But I can try to test on my own personal time if there are potential fixes to this in order to assist the community as there might be other users of wrapped CPP objects who do not want to remove the five commits listed above which might also become more complicated to do cleanly in the future as newer changes and made on top of them.
I have attached six sample errors from valgrind below:
==6742== Invalid read of size 8
==6742== at 0x884B718: PyObject_ClearWeakRefs (in /usr/lib64/libpython2.7.so.
1.0)
==6742== by 0x883C1DF: ??? (in /usr/lib64/libpython2.7.so.1.0)
==6742== by 0x883A0D2: ??? (in /usr/lib64/libpython2.7.so.1.0)
==6742== by 0x883A0D2: ??? (in /usr/lib64/libpython2.7.so.1.0)
==6742== by 0x8D266C9: PythonQtSignalTarget::call(_object*, PythonQtMethodInf
o const*, void**, bool) (in /home/xxx/git/qtbuild/libPythonQt-Qt5-Python2.7.so.3
.2.0)
==6742== by 0x8D267EA: PythonQtSignalTarget::call(void**) const (in /home/xxx
/git/qtbuild/libPythonQt-Qt5-Python2.7.so.3.2.0)
==6742== by 0x8D27049: PythonQtSignalReceiver::qt_metacall(QMetaObject::Call,
int, void**) (in /home/xxx/git/qtbuild/libPythonQt-Qt5-Python2.7.so.3.2.0)
==6742== by 0xD8FF143: QMetaObject::activate(QObject*, int, int, void**) (in
/usr/lib64/libQt5Core.so.5.9.7)
[...]
==6742== Address 0xa379d5b0 is 240 bytes inside an unallocated block of size 96
0 in arena "client"
==6742==
==6742== Invalid write of size 8
==6742== at 0x883BC3F: ??? (in /usr/lib64/libpython2.7.so.1.0)
==6742== by 0x883C1CA: ??? (in /usr/lib64/libpython2.7.so.1.0)
==6742== by 0x883A0D2: ??? (in /usr/lib64/libpython2.7.so.1.0)
==6742== by 0x883A0D2: ??? (in /usr/lib64/libpython2.7.so.1.0)
==6742== by 0x8D266C9: PythonQtSignalTarget::call(_object*, PythonQtMethodInf
o const*, void**, bool) (in /home/xxx/git/qtbuild/libPythonQt-Qt5-Python2.7.so.3
.2.0)
==6742== by 0x8D267EA: PythonQtSignalTarget::call(void**) const (in /home/xxx
/git/qtbuild/libPythonQt-Qt5-Python2.7.so.3.2.0)
==6742== by 0x8D27049: PythonQtSignalReceiver::qt_metacall(QMetaObject::Call,
int, void**) (in /home/xxx/git/qtbuild/libPythonQt-Qt5-Python2.7.so.3.2.0)
==6742== by 0xD8FF143: QMetaObject::activate(QObject*, int, int, void**) (in
/usr/lib64/libQt5Core.so.5.9.7)
[...]
==6742== Address 0x8 is not stack'd, malloc'd or (recently) free'd
==6742== Invalid read of size 8
==6742== at 0x87EA03B: PyObject_Call (in /usr/lib64/libpython2.7.so.1.0)
==6742== by 0x8C7BDBF: PythonQtPrivate::createNewPythonQtInstanceWrapper(QObject*, PythonQtClassInfo*, void*) (in /home/xxx/git/qtbuild/libPythonQt-Qt5-Python2.7.so.3.2.0)
==6742== by 0x8C7DB10: PythonQtPrivate::wrapPtr(void*, QByteArray const&, bool) (in /home/xxx/git/qtbuild/libPythonQt-Qt5-Python2.7.so.3.2.0)
==6742== by 0x8D218C6: PythonQtConv::createCopyFromMetaType(int, void const*) (in /home/xxx/git/qtbuild/libPythonQt-Qt5-Python2.7.so.3.2.0)
==6742== by 0x8D22662: PythonQtConv::QVariantListToPyObject(QList<QVariant> const&) (in /home/xxx/git/qtbuild/libPythonQt-Qt5-Python2.7.so.3.2.0)
==6742== by 0x8D266B1: PythonQtSignalTarget::call(_object*, PythonQtMethodInfo const*, void**, bool) (in /home/xxx/git/qtbuild/libPythonQt-Qt5-Python2.7.so.3.2.0)
==6742== by 0x8D267EA: PythonQtSignalTarget::call(void**) const (in /home/xxx/git/qtbuild/libPythonQt-Qt5-Python2.7.so.3.2.0)
==6742== by 0x8D27049: PythonQtSignalReceiver::qt_metacall(QMetaObject::Call, int, void**) (in /home/xxx/git/qtbuild/libPythonQt-Qt5-Python2.7.so.3.2.0)
==6742== by 0xD8FF143: QMetaObject::activate(QObject*, int, int, void**) (in /usr/lib64/libQt5Core.so.5.9.7)
[...]
==6742== Address 0xa379d4e8 is 40 bytes inside an unallocated block of size 960 in arena "client"
==6742== Invalid read of size 1
==6742== at 0x883F8C0: PyType_IsSubtype (in /usr/lib64/libpython2.7.so.1.0)
==6742== by 0x8D145E8: PythonQtMemberFunction_Call(PythonQtSlotInfo*, _object
*, _object*, _object*) (in /home/xxx/git/qtbuild/libPythonQt-Qt5-Python2.7.so.3.
2.0)
==6742== by 0x87EA072: PyObject_Call (in /usr/lib64/libpython2.7.so.1.0)
==6742== by 0x887E845: PyEval_EvalFrameEx (in /usr/lib64/libpython2.7.so.1.0)
==6742== by 0x888564C: PyEval_EvalCodeEx (in /usr/lib64/libpython2.7.so.1.0)
==6742== by 0x880EF87: ??? (in /usr/lib64/libpython2.7.so.1.0)
==6742== by 0x87EA072: PyObject_Call (in /usr/lib64/libpython2.7.so.1.0)
==6742== by 0x87F9064: ??? (in /usr/lib64/libpython2.7.so.1.0)
==6742== by 0x87EA072: PyObject_Call (in /usr/lib64/libpython2.7.so.1.0)
==6742== by 0x887BF06: PyEval_CallObjectWithKeywords (in /usr/lib64/libpython
2.7.so.1.0)
==6742== by 0x8D26723: PythonQtSignalTarget::call(_object*, PythonQtMethodInf
o const*, void**, bool) (in /home/xxx/git/qtbuild/libPythonQt-Qt5-Python2.7.so.3
.2.0)
==6742== by 0x8D267EA: PythonQtSignalTarget::call(void**) const (in /home/xxx
/git/qtbuild/libPythonQt-Qt5-Python2.7.so.3.2.0)
==6742== Address 0xa379d589 is 201 bytes inside an unallocated block of size 96
0 in arena "client"
==6742== Invalid read of size 8
==6742== at 0x8D14A2C: PythonQtMemberFunction_Call(PythonQtSlotInfo*, _object*, _object*, _object*) (in /home/xxx/git/qtbuild/libPythonQt-Qt5-Python2.7.so.3.2.0)
==6742== by 0x87EA072: PyObject_Call (in /usr/lib64/libpython2.7.so.1.0)
==6742== by 0x887E845: PyEval_EvalFrameEx (in /usr/lib64/libpython2.7.so.1.0)
==6742== by 0x888564C: PyEval_EvalCodeEx (in /usr/lib64/libpython2.7.so.1.0)
==6742== by 0x880EF87: ??? (in /usr/lib64/libpython2.7.so.1.0)
==6742== by 0x87EA072: PyObject_Call (in /usr/lib64/libpython2.7.so.1.0)
==6742== by 0x87F9064: ??? (in /usr/lib64/libpython2.7.so.1.0)
==6742== by 0x87EA072: PyObject_Call (in /usr/lib64/libpython2.7.so.1.0)
==6742== by 0x887BF06: PyEval_CallObjectWithKeywords (in /usr/lib64/libpython2.7.so.1.0)
==6742== by 0x8D26723: PythonQtSignalTarget::call(_object*, PythonQtMethodInfo const*, void**, bool) (in /home/xxx/git/qtbuild/libPythonQt-Qt5-Python2.7.so.3.2.0)
==6742== by 0x8D267EA: PythonQtSignalTarget::call(void**) const (in /home/xxx/git/qtbuild/libPythonQt-Qt5-Python2.7.so.3.2.0)
==6742== by 0x8D27049: PythonQtSignalReceiver::qt_metacall(QMetaObject::Call, int, void**) (in /home/xxx/git/qtbuild/libPythonQt-Qt5-Python2.7.so.3.2.0)
==6742== Address 0xa379d848 is 904 bytes inside an unallocated block of size 960 in arena "client"
==6742==
==6742== Invalid read of size 1
==6742== at 0x883B7B8: PyType_GenericAlloc (in /usr/lib64/libpython2.7.so.1.0
)
==6742== by 0x8D27691: PythonQtInstanceWrapper_new(_typeobject*, _object*, _object*) (in /home/xxx/git/qtbuild/libPythonQt-Qt5-Python2.7.so.3.2.0)
==6742== by 0x883FD62: ??? (in /usr/lib64/libpython2.7.so.1.0)
==6742== by 0x87EA072: PyObject_Call (in /usr/lib64/libpython2.7.so.1.0)
==6742== by 0x8C7BDBF: PythonQtPrivate::createNewPythonQtInstanceWrapper(QObject*, PythonQtClassInfo*, void*) (in /home/xxx/git/qtbuild/libPythonQt-Qt5-Python2.7.so.3.2.0)
==6742== by 0x8C7DB10: PythonQtPrivate::wrapPtr(void*, QByteArray const&, bool) (in /home/xxx/git/qtbuild/libPythonQt-Qt5-Python2.7.so.3.2.0)
==6742== by 0x8D218C6: PythonQtConv::createCopyFromMetaType(int, void const*) (in /home/xxx/git/qtbuild/libPythonQt-Qt5-Python2.7.so.3.2.0)
==6742== by 0x8D22662: PythonQtConv::QVariantListToPyObject(QList<QVariant> const&) (in /home/xxx/git/qtbuild/libPythonQt-Qt5-Python2.7.so.3.2.0)
==6742== by 0x8D266B1: PythonQtSignalTarget::call(_object*, PythonQtMethodInfo const*, void**, bool) (in /home/xxx/git/qtbuild/libPythonQt-Qt5-Python2.7.so.3.2.0)
==6742== by 0x8D267EA: PythonQtSignalTarget::call(void**) const (in /home/xxx/git/qtbuild/libPythonQt-Qt5-Python2.7.so.3.2.0)
==6742== by 0x8D27049: PythonQtSignalReceiver::qt_metacall(QMetaObject::Call, int, void**) (in /home/xxx/git/qtbuild/libPythonQt-Qt5-Python2.7.so.3.2.0)
==6742== by 0xD8FF143: QMetaObject::activate(QObject*, int, int, void**) (in /usr/lib64/libQt5Core.so.5.9.7)
==6742== Address 0xa379d589 is 201 bytes inside an unallocated block of size 960 in arena "client"
Can confirm I'm seeing this same issue working from the same December 2 commit https://github.com/MeVisLab/pythonqt/commit/9ea0fcfd73f9d434066e3b73a6bd3db76da78f9f.
In my case, there are no custom types involved. I'm just passing some heavily nested VariantMaps and VariantLists through to Python. The crash is in the same spot and I suspect for the same reason. And it also occurs randomly indicating likely use after free issues. I can do the same operation one time and it works and the next time it fails.
My stacktrace looks like this (Windows):
1 PyObject_Call call.c 226 0x7ffac0a3ab71
2 PythonQtPrivate::wrapPtr PythonQt_Qt5_Python38 0x7ffacaa2a7bd
3 PythonQtConv::createCopyFromMetaType PythonQt_Qt5_Python38 0x7ffacaa42b5d
4 PythonQtConv::QVariantMapToPyObject PythonQt_Qt5_Python38 0x7ffacaa424a1
5 PythonQtConv::QVariantListToPyObject PythonQt_Qt5_Python38 0x7ffacaa42382
6 PythonQtConv::QVariantMapToPyObject PythonQt_Qt5_Python38 0x7ffacaa424a1
7 PythonQtConv::QVariantListToPyObject PythonQt_Qt5_Python38 0x7ffacaa42382
8 PythonQtConv::QVariantMapToPyObject PythonQt_Qt5_Python38 0x7ffacaa424a1
9 PythonQtConv::QVariantListToPyObject PythonQt_Qt5_Python38 0x7ffacaa42382
10 PythonQtConv::QVariantMapToPyObject PythonQt_Qt5_Python38 0x7ffacaa424a1
11 PythonQtConv::QVariantMapToPyObject PythonQt_Qt5_Python38 0x7ffacaa424a1
12 PythonQtObjectPtr::toVariant PythonQt_Qt5_Python38 0x7ffacaa35eff
13 PythonQtObjectPtr::toVariant PythonQt_Qt5_Python38 0x7ffacaa3753b
14 PythonQtObjectPtr::toVariant PythonQt_Qt5_Python38 0x7ffacaa36873
15 _PyEval_EvalFrameDefault ceval.c 3469 0x7ffac0a8afe2
16 _PyEval_EvalFrameDefault ceval.c 3500 0x7ffac0a88c04
17 _PyEval_EvalCodeWithName ceval.c 4298 0x7ffac0a84838
18 _PyFunction_Vectorcall call.c 435 0x7ffac0a85fbf
19 PyVectorcall_Call call.c 199 0x7ffac0a3c56a
20 PyObject_Call call.c 251 0x7ffac0a3ab91
21 PythonQt::callAndReturnPyObject PythonQt_Qt5_Python38 0x7ffacaa0283f
22 PythonQt::call PythonQt_Qt5_Python38 0x7ffacaa02655
23 PythonQt::call PythonQt_Qt5_Python38 0x7ffacaa02756
24 PythonQtObjectPtr::call PythonQt_Qt5_Python38 0x7ffacaa33385
25 image00007ff7_87d60000 0x7ff787d62961
26 image00007ff7_87d60000 0x7ff787d66262
27 image00007ff7_87d60000 0x7ff787d661bf
28 QQmlObjectOrGadget::metacall qqmlobjectorgadget.cpp 58 0x7ffac60422b1
29 CallMethod qv4qobjectwrapper.cpp 1303 0x7ffac5f5bf10
30 CallPrecise qv4qobjectwrapper.cpp 1569 0x7ffac5f5ca2d
31 QV4::QObjectMethod::callInternal qv4qobjectwrapper.cpp 2133 0x7ffac5f5df81
32 QV4::Moth::VME::interpret qv4vme_moth.cpp 754 0x7ffac5f74148
33 QV4::Moth::VME::exec qv4vme_moth.cpp 466 0x7ffac5f71a2b
34 QV4::ArrowFunction::virtualCall qv4functionobject.cpp 530 0x7ffac5f26ea0
35 QV4::Moth::VME::interpret qv4vme_moth.cpp 754 0x7ffac5f74148
36 QV4::Moth::VME::exec qv4vme_moth.cpp 466 0x7ffac5f71a2b
37 QV4::ArrowFunction::virtualCall qv4functionobject.cpp 530 0x7ffac5f26ea0
38 QV4::Runtime::CallPropertyLookup::call qv4runtime.cpp 1460 0x7ffac5f7efe6
39 0x1ddee3c1137
40 QV4::Moth::VME::exec qv4vme_moth.cpp 460 0x7ffac5f71a0f
41 QV4::ArrowFunction::virtualCall qv4functionobject.cpp 530 0x7ffac5f26ea0
42 QQmlDelayedCallQueue::DelayedFunctionCall::execute qqmldelayedcallqueue.cpp 79 0x7ffac606fba0
43 QQmlDelayedCallQueue::executeAllExpired_Later qqmldelayedcallqueue.cpp 204 0x7ffac606feda
44 QObject::event qobject.cpp 1314 0x7ffac10295c1
45 QApplicationPrivate::notify_helper qapplication.cpp 3634 0x7ffac2094990
46 QApplication::notify qapplication.cpp 3586 0x7ffac2093a13
47 QCoreApplication::notifyInternal2 qcoreapplication.cpp 1063 0x7ffac1002aca
48 QCoreApplicationPrivate::sendPostedEvents qcoreapplication.cpp 1817 0x7ffac1004845
49 QWindowsGuiEventDispatcher::sendPostedEvents qwindowsguieventdispatcher.cpp 81 0x7ffac6d92dff
50 QEventDispatcherWin32::processEvents qeventdispatcher_win.cpp 530 0x7ffac104ba5a
51 QWindowsGuiEventDispatcher::processEvents qwindowsguieventdispatcher.cpp 74 0x7ffac6d92dd9
52 QEventLoop::exec qeventloop.cpp 232 0x7ffac0ffef2c
53 QCoreApplication::exec qcoreapplication.cpp 1371 0x7ffac1001a94
54 image00007ff7_87d60000 0x7ff787d61fc8
55 image00007ff7_87d60000 0x7ff787d678d7
56 image00007ff7_87d60000 0x7ff787d66d0a
57 BaseThreadInitThunk KERNEL32 0x7ffb10817034
58 RtlUserThreadStart ntdll 0x7ffb11822651
I'm going to attempt reverting those same commits (thank you @he-hesce!).
Confirmed. Branching off of https://github.com/MeVisLab/pythonqt/commit/9ea0fcfd73f9d434066e3b73a6bd3db76da78f9f and reverting these commits:
pick 06860d4 Fix reference/memory leaks pick 525ea41 More potential leak fixes and build fix pick 295a9ce Stylistic changes and refcount fixes in PythonQtImporter_load_module pick 383fb8e Allow setting PYTHON_VERSION and PYTHON_DIR when including python.prf, add rpath pick 9ea0fcf Fix name clash with Visual Studio 2017
seems to have stopped the invalid memory accesses.
I have created a branch "revert-refcount-fixes" in which the relevant commits are reverted (but I spared the changes to python.prf, since I don't believe that they caused this problem). I would like to have the refcount fixes, but don't have the time to look into this.
@davidkhess: Great and thanks to see a confirmation on this issue.
@usiems: Great and thanks, this will allow us to upgrade to later PythonQt revisions in the future.
@he-hesce - the problematic commits have been reverted some time ago, so I guess this not an issue anymore?
@mrbean-bremen : Indeed, this is not an issue after the commits were reverted. Current tagged release is solid as a rock.