Bug 279319
| Summary: | deskutils/calibre: calibre-server dumps core (7.10.0) | ||
|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Matthias Pfaller <matthias.pfaller> |
| Component: | Individual Port(s) | Assignee: | Guido Falsi <madpilot> |
| Status: | Closed Overcome By Events | ||
| Severity: | Affects Only Me | CC: | kde |
| Priority: | --- | Flags: | madpilot:
maintainer-feedback+
|
| Version: | Latest | ||
| Hardware: | amd64 | ||
| OS: | Any | ||
Hi, Thanks for reporting. First of all I just committed a new calibre release (7.11.0), so I'd like to know if the issue still happens with that one. After this, I also have other qt6 programs I maintains showing issues after the recent QT upgrade to 6.7.1 [1]. From you backtrace the issue appears to happen inside libQt6Gui.so.6. If that's actually the case there is little to be done in downstream projects to fix it. To help nail down this issue you should compile qt6-base-6.7.1 with debug symbols enabled, can be done using WITH_DEBUG_PORTS in make.conf and backtrace with debugging on, so we could know where exactly in the library it is crashing. I'm also adding kde@FreeBSD.org in case they are interested. [1] For example editors/ghostwriter is crashing in a very similar way. multimedia/audacious-plugins fails to build with an assertion error I'm not able to parse, I've reported it upstream hoping they know better. Hi Guido, I'll try 7.11, but I think it won't help. Does calling calibre-server crash for you as well? I'll rebuild with DEBUG after trying 7.11, but all that will take a lot of time on my poor microserver-g8 (Xeon E3-1220L with 16gb of ram...). Matthias (In reply to Matthias Pfaller from comment #2) It is actually running here: > sudo service calibre onestart Starting calibre. > ps -axwww | grep calibre 25026 - I 0:00.40 /usr/local/bin/python3.9 /usr/local/bin/calibre-server --log /var/log/calibre-server/calibre-server.log --pidfile /var/run/calibre/calibre.pid --max-log-size 10 --daemonize <directory redacted> Actually reinstalling calibre and/or some QT parts could "fix" the issue. This is common to some QT programs. For example I need to force reinstall telegram-desktop-qt6 each time qt is upgraded. My machine is rebuilding qt6-base at this moment. Usually synth does quite a good job at rebuilding whatever is necessary. (In reply to Matthias Pfaller from comment #4) The fact that it works fine here leaves me even more confused. I've not been using synth for a long time, I use poudriere, which is quite more conservative, maybe it builds too much most of the time but avoids most pitfalls. If you have some ABI or API desync on your machine with libraries installed by ports/packages, getting to the root of it can be quite daunting. In the old days when I was building things locally I often ended up rebuilding bunches of libraries. Poudriere (and mostly synth I guess) makes things a little easier, at worst a "pkg upgrade -f" forces everything fresh installed and gets rid of a lot of messy situations. Not having it fail here I suspect this could be a local issue on your machine. After seven hours synth was done :-/ The following packages were upgraded: May 27 07:18:55 zork pkg[81268]: jpeg-turbo upgraded: 3.0.2 -> 3.0.3 May 27 07:18:55 zork pkg[81268]: libxml2 upgraded: 2.11.7 -> 2.11.8 May 27 07:18:55 zork pkg[81268]: librsvg2-rust upgraded: 2.58.0_2 -> 2.58.1 May 27 07:18:55 zork pkg[81268]: assimp upgraded: 5.4.0 -> 5.4.1 May 27 07:18:56 zork pkg[81268]: dav1d upgraded: 1.4.1 -> 1.4.2 May 27 07:18:56 zork pkg[81268]: mesa-libs upgraded: 24.0.7 -> 24.0.8 May 27 07:18:59 zork pkg[81268]: mariadb106-client upgraded: 10.6.17 -> 10.6.18 May 27 07:19:00 zork pkg[81268]: samba416 upgraded: 4.16.11_4 -> 4.16.11_5 May 27 07:19:05 zork pkg[81268]: mariadb106-server upgraded: 10.6.17 -> 10.6.18 May 27 07:19:06 zork pkg[81268]: calibre upgraded: 7.10.0 -> 7.11.0 calibre-server is working again. I had this problem since 2024-05-19 after upgrading from qt6.6.3 to qt6.7.0. I hoped the upgrade to 6.7.1 would help, but it didn't. But now it magically just works again :-) Thank's again for providing calibre on FreeBSD. |
After the last update my calibre-server will no longer start. It aborts with a core dump on SIGBUS. calibre itself is working. best regards, Matthias (lldb) bt * thread #1, name = 'python3.9', stop reason = signal SIGBUS * frame #0: 0x0000000853d205a6 libQt6Gui.so.6`___lldb_unnamed_symbol16007 + 438 frame #1: 0x0000000853d14f94 libQt6Gui.so.6`___lldb_unnamed_symbol15983 + 5124 frame #2: 0x0000000853d138d8 libQt6Gui.so.6`QGuiApplicationPrivate::createPlatformIntegration() + 2360 frame #3: 0x0000000853d15e90 libQt6Gui.so.6`QGuiApplicationPrivate::createEventDispatcher() + 32 frame #4: 0x000000084b11ebd4 libQt6Core.so.6`QCoreApplicationPrivate::init() + 1796 frame #5: 0x0000000853d0f69a libQt6Gui.so.6`QGuiApplicationPrivate::init() + 42 frame #6: 0x00000008692f9927 libQt6Widgets.so.6`QApplicationPrivate::init() + 39 frame #7: 0x0000000865ef324e QtWidgets.abi3.so`sipQApplication::sipQApplication(int&, char**, int) + 14 frame #8: 0x0000000865ef38db QtWidgets.abi3.so`___lldb_unnamed_symbol26895 + 171 frame #9: 0x00000008504c0cc7 sip.cpython-39.so`sipSimpleWrapper_init + 423 frame #10: 0x0000000822e159b1 libpython3.9.so.1.0`___lldb_unnamed_symbol4782 + 337 frame #11: 0x0000000822dc0abe libpython3.9.so.1.0`_PyObject_MakeTpCall + 366 frame #12: 0x0000000822e8860c libpython3.9.so.1.0`___lldb_unnamed_symbol5461 + 620 frame #13: 0x0000000822e85587 libpython3.9.so.1.0`_PyEval_EvalFrameDefault + 23687 frame #14: 0x0000000822dc12da libpython3.9.so.1.0`___lldb_unnamed_symbol3862 + 170 frame #15: 0x0000000822e8853b libpython3.9.so.1.0`___lldb_unnamed_symbol5461 + 411 frame #16: 0x0000000822e85587 libpython3.9.so.1.0`_PyEval_EvalFrameDefault + 23687 frame #17: 0x0000000822e89136 libpython3.9.so.1.0`___lldb_unnamed_symbol5462 + 2118 frame #18: 0x0000000822dc11d5 libpython3.9.so.1.0`_PyFunction_Vectorcall + 261 frame #19: 0x0000000822e8853b libpython3.9.so.1.0`___lldb_unnamed_symbol5461 + 411 frame #20: 0x0000000822e85587 libpython3.9.so.1.0`_PyEval_EvalFrameDefault + 23687 frame #21: 0x0000000822e89136 libpython3.9.so.1.0`___lldb_unnamed_symbol5462 + 2118 frame #22: 0x0000000822e7f801 libpython3.9.so.1.0`PyEval_EvalCode + 81 frame #23: 0x0000000822ec4f91 libpython3.9.so.1.0`___lldb_unnamed_symbol5781 + 177 frame #24: 0x0000000822ec5129 libpython3.9.so.1.0`___lldb_unnamed_symbol5782 + 201 frame #25: 0x0000000822ec35ab libpython3.9.so.1.0`PyRun_SimpleFileExFlags + 923 frame #26: 0x0000000822ee0103 libpython3.9.so.1.0`Py_RunMain + 2115 frame #27: 0x0000000822ee05e5 libpython3.9.so.1.0`___lldb_unnamed_symbol5933 + 389 frame #28: 0x0000000822ee065a libpython3.9.so.1.0`Py_BytesMain + 58 frame #29: 0x0000000825d47afa libc.so.7`__libc_start1 + 298 frame #30: 0x00000000002016d0 python3.9`_start + 48