search

MeVisLab / pythonqt

Dynamic Python binding for Qt Applications
https://mevislab.github.io/pythonqt/
GNU Lesser General Public License v2.1
248 stars 89 forks source link

Segfault in PythonQtPrivate::createNewPythonQtInstanceWrapper #33

Closed he-hesce closed 10 months ago

he-hesce commented 3 years ago

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.

usiems commented 3 years ago

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.

he-hesce commented 3 years ago

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.

he-hesce commented 3 years ago

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.

he-hesce commented 3 years ago

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.

he-hesce commented 3 years ago

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.

usiems commented 3 years ago

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.

he-hesce commented 3 years ago

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.

he-hesce commented 3 years ago

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.

gregor-anich-uibk commented 3 years ago

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.

he-hesce commented 3 years ago

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"
davidkhess commented 3 years ago

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!).

davidkhess commented 3 years ago

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.

usiems commented 3 years ago

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.

he-hesce commented 3 years ago

@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.

mrbean-bremen commented 10 months ago

@he-hesce - the problematic commits have been reverted some time ago, so I guess this not an issue anymore?

he-hesce commented 10 months ago

@mrbean-bremen : Indeed, this is not an issue after the commits were reverted. Current tagged release is solid as a rock.