Issue with Python 3.10 package

Help
1

Hello. I would like to ask for some help, related to an issue that I am facing trying to run a Python / PyQt application.
The application is QTodoTxt (GitHub - QTodoTxt/QTodoTxt: Cross Platform todo.txt GUI)

At least, until hrev57740 (32 bit) the application was working fine. The Python packages that I had installed are the following:

state_2024-05-30_00:36:11/activated-packages:six_python310-1.15.0-5-any.hpkg
state_2024-05-30_00:36:11/activated-packages:pyqt5_x86_python310-5.15.10-3-x86_gcc2.hpkg
state_2024-05-30_00:36:11/activated-packages:pyqt5_sip_x86_python310-12.13.0-1-x86_gcc2.hpkg
state_2024-05-30_00:36:11/activated-packages:dateutil_python310-2.8.2-2-any.hpkg
state_2024-05-30_00:36:11/activated-packages:python3.10_x86-3.10.13-3-x86_gcc2.hpkg

However, after upgrading to hrev hrev57768 (June 19, 2024), the application crashes when try to start it.

Crash report: https://0x0.st/XLlh.txt

I reviewed my Python packages, so see if there was some changes, but I am seeing that the Python packages were not updated since hrev57740:

state_2024-07-03_20:48:37/activated-packages:six_python310-1.15.0-5-any.hpkg
state_2024-07-03_20:48:37/activated-packages:pyqt5_sip_x86_python310-12.13.0-1-x86_gcc2.hpkg
state_2024-07-03_20:48:37/activated-packages:pyqt5_x86_python310-5.15.10-3-x86_gcc2.hpkg
state_2024-07-03_20:48:37/activated-packages:dateutil_python310-2.8.2-2-any.hpkg
state_2024-07-03_20:48:37/activated-packages:python3.10_x86-3.10.13-3-x86_gcc2.hpkg

So, the crash is caused by some change in other component. There is something in the crash report that could help me to identify where is the issue? Maybe in Haiku side? or other Haikuport package?

Any advise is welcome! :slight_smile:

2

My wild guess is… some sort of mismatch between pyqt5_sip’s (or pyqt5_x86’s) binaries, and qt5 ones. The former were last compiled 8 months ago, while qt5 just 2 months ago, and we had some changes in gcc packages.

Maybe a rebuild of those packages against current Qt5 libs is needed. In any case, I’m currently working on getting Python 3.10.14 available soon.

off-topic P.S: ¡Aguante Argentina campeón de América! (me siento como los locos de “The IT Crowd”, hablando de fútbol, sin endender un pomo… “Did you see that ludicrous display last night?” :crazy_face:

1 Like
3

No idea, but quick check/run in Terminal also shows:

~/config/non-packaged/bin> qtodotxt 
Traceback (most recent call last):
  File "/boot/home/config/non-packaged/lib/python3.10/site-packages/qtodotxt/ui/views/tasks_search_view.py", line 41, in resizeEvent
    self.clearButton.move(self.rect().right() - frameWidth - sz.width(),
TypeError: arguments did not match any overloaded call:
  move(self, a0: QPoint): argument 1 has unexpected type 'int'
  move(self, ax: int, ay: int): argument 2 has unexpected type 'float'
Abort
Kill Thread

Maybe @BiPolar has any idea :slight_smile:

4

With the little I know… seeing __cxa_rethrow in the crash log makes me think of problems with exception handling / uncaught exception, possibly due to compiler’s versions mismatch/changes?

As usual… I barely know what I’m talking about :smiley:, so… better we wait for the “big guys” to help us out.

5

This probably has to do with the fix to GCC on 32-bit as regards unwind information.

I would do a full-sync of packages and get up to the latest nightly hrev, the problem may be fixed with the new GCC/binutils-compiled builds.

6

Hello. Thanks for the answers! :slight_smile:

Just in case you find useful, I tried gain using the new Python 3.10.14-1 package , but is still crashing:

https://0x0.st/X9_c.report

Anyways, looks like the issue is on Python side, so makes sense to report the issue to Haikuports.

7

The pyqt5_sip package also got updated recently (but if you got the Python 3.10.14 update via pkgman update, you should have gotten that one anyway).

While the code starts being called from a Python process, the call trace goes pretty deep into Qt code before failing:

debugger + 0x31 
abort + 0x51 
/boot/system/lib/x86/libroot.so + 0xba69b 
__cxxabiv1::__terminate(void (*)()) + 0x10 
/boot/system/lib/x86/libroot.so + 0xb988e 
__cxa_rethrow + 0x63 
__gnu_cxx::__verbose_terminate_handler() [clone .cold] + 0x65 
__cxxabiv1::__terminate(void (*)()) + 0x10 
/boot/system/lib/x86/libroot.so + 0xb988e 
/boot/system/lib/x86/libroot.so + 0xb9a2c 
BPrivate::Storage::ResourceFile::_InitFile(BFile&, bool) [clone .cold] + 0x39 
BPrivate::Storage::ResourceFile::SetTo(BFile*, bool) + 0x40 
BResources::SetTo(BFile const*, bool) + 0x107 
BAppFileInfo::SetTo(BFile*) + 0xf0 
BAppFileInfo::BAppFileInfo(BFile*) + 0x3f 
QHaikuIntegration::createHaikuIntegration(QStringList const&, int&, char**) + 0x7ea 
QHaikuExpIntegrationPlugin::create(QString const&, QStringList const&, int&, char**) + 0x3c 
QGuiApplicationPrivate::createPlatformIntegration() + 0x848 
QGuiApplicationPrivate::createEventDispatcher() + 0x47 
QApplicationPrivate::createEventDispatcher() + 0x16 
QCoreApplicationPrivate::init() + 0x92a 
QGuiApplicationPrivate::init() + 0x1b 
QApplicationPrivate::init() + 0x17 
QApplication::QApplication(int&, char**, int) + 0x4f 
sipQApplication::sipQApplication(int&, char**, int) + 0x20 
init_type_QApplication + 0x98 
sipSimpleWrapper_init + 0x450 
type_call + 0xc2 
_PyObject_MakeTpCall + 0x79

So it still looks to me like the problem is outside of Python. In any case, yes, please report the problem over HaikuPorts.

1 Like
8

The ResourceFile code sets up an exception handler, but it looks like the handler isn’t catching exceptions. This is the problem that should’ve been solved by the new revision of GCC, but maybe there is some incompatibility with Qt here. A rebuild of Qt on 32-bit may be necessary.

1 Like
9

If Qt5 would be split like Qt6 it wouldn’t be a monster to tackle then :slight_smile: Or we could just revbump it to the buildmasters?

10

Just for tracking purposes, I submitted the ticket at HaikuPorts page. Thank you!!!