UI segfaults frequently (on Manjaro & Gnome & Wayland)

[declension]

Apologies if this is just upstream bugs, but it's driving me a bit crazy 😞 - can be segfaulting 10+ times an evening sometimes. Other UIs don't seem to have this, though I don't use many QT apps here.

Describe the bug
Using the UI (maybe changing windows especially) often now results in a segfault for me, with dmesg saying:

segfault at 558600000019 ip 00007fea877f8c31 sp 00007ffc1a15bbe0 error 4 in libqgnomeplatformdecoration.so[7fea877f7000+5000]

To Reproduce
Use it on an affected system, move the window around lots, chat, resize, press buttons, stuff like that.

Expected behavior
Never segfault

Operating system

• Manjaro Linux
• Kernel 5.15.146-1-MANJARO #1 SMP PREEMPT Fri Jan 5 16:20:43 UTC 2024 x86_64 GNU/Linux
• Gnome 45.3
• Wayland

Version of Jamulus
3.10.0 (QT: 6.5.0)

Additional context

This started happening in the last month or two

[declension]

Related maybe: https://bugs.archlinux.org/task/76109

Not sure if this is relevant, but maybe QT6.6 offers some hope? http://blog.davidedmundson.co.uk/blog/qt6_wayland_robustness/

[ann0see]

Sounds a bit like what we experienced in the past here: #3204 and something else #3070 Qt6 seems to be buggy.

[ann0see]

I don't think we can really do much instead of hoping that Arch bundles a newer Qt6 version?

@jujudusud is involved in the aur on arch, I think. Maybe he can comment too?

[jujudusud]

Manjaro is not exactly the same as archlinux.
I don't know much in Manjaro.
That said, please update Qt to 6.6.1 on your Manjaro.
You use Wayland. How do you build Jamulus?

[declension]

Thanks both.

That said, please update Qt to 6.6.1 on your Manjaro.

Hmmm, I'm already on 6.6.1 actually:

❯ pacman --sync --info qt6-base
Repository      : extra
Name            : qt6-base
Version         : 6.6.1-3
...

You use Wayland. How do you build Jamulus?

I got it from the Manjaro AUR, i.e.

sudo pamac install jamulus

which I believe is mirrored from https://github.com/osam-cologne/archlinux-proaudio right?

Maybe (@ann0see esp) the help text is out of date then:

❯ jamulus --version
 *** Jamulus, Version 3.10.0
 *** Internet Jam Session Software
 *** Released under the GNU General Public License version 2 or later (GPLv2)
 *** <https://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
 ***
 *** This program is free software; you can redistribute it and/or modify it under
 *** the terms of the GNU General Public License as published by the Free Software
 *** Foundation; either version 2 of the License, or (at your option) any later version.
 *** There is NO WARRANTY, to the extent permitted by law.
 ***
 *** Using the following libraries, resources or code snippets:
 ***
 *** Qt framework 6.5.2
 *** <https://doc.qt.io/qt-5/lgpl.html>
 ***
 *** Opus Interactive Audio Codec
 *** <https://www.opus-codec.org>
 ***
 *** Audio reverberation code by Perry R. Cook and Gary P. Scavone
 *** <https://ccrma.stanford.edu/software/stk>
 ***
 *** Some pixmaps are from the Open Clip Art Library (OCAL)
 *** <https://openclipart.org>
 ***
 *** Flag icons by Mark James
 *** <http://www.famfamfam.com>
 ***
 *** Some sound samples are from Freesound
 *** <https://freesound.org>
 ***
 *** Copyright © 2005-2023 The Jamulus Development Team

Definitely the qt5 URL is wrong! (here I think)

But is QT_VERSION_STR is definitely accurate?

[softins]

That suggests that your jamulus binary was built with Qt 6.5.2 embedded, rather than using dynamic linking.

Check what shared libs it is pulling in by using: ldd $(which jamulus)

[cbix]

That suggests that your jamulus binary was built with Qt 6.5.2 embedded, rather than using dynamic linking

Since QT_VERSION_STR comes from the header at compile time it prints that Qt version, even though Qt is actually dynamically linked:

~$ ldd /usr/bin/jamulus 
	linux-vdso.so.1 (0x00007ffec07f0000)
	libjack.so.0 => /usr/lib/libjack.so.0 (0x00007a43c17d9000)
	libQt6Widgets.so.6 => /usr/lib/libQt6Widgets.so.6 (0x00007a43c0c00000)
	libQt6Multimedia.so.6 => /usr/lib/libQt6Multimedia.so.6 (0x00007a43c0b14000)
	libQt6Gui.so.6 => /usr/lib/libQt6Gui.so.6 (0x00007a43c0200000)
	libQt6Network.so.6 => /usr/lib/libQt6Network.so.6 (0x00007a43c0068000)
	libQt6Xml.so.6 => /usr/lib/libQt6Xml.so.6 (0x00007a43c17b4000)
	libQt6Core.so.6 => /usr/lib/libQt6Core.so.6 (0x00007a43bfa00000)
	libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007a43bf600000)
[...]

I'm using the same package on Arch/Gnome/Wayland as @declension but can't reproduce any segfaults. Anyway for more detailed debugging you could use coredumpctl + debuginfod, which makes gdb download any missing debug symbols for debugging:

coredumpctl info /usr/bin/jamulus
coredumpctl debug /usr/bin/jamulus
bt # (inside gdb)

You could also try rebuilding jamulus first (i.e. "reinstall" from AUR) to rule out any weird issues caused by any faulty updated dependencies 🤔

[softins]

That suggests that your jamulus binary was built with Qt 6.5.2 embedded, rather than using dynamic linking

Since QT_VERSION_STR comes from the header at compile time it prints that Qt version, even though Qt is actually dynamically linked:

You are right, and I've just confirmed that in a build of mine on RPi. I think that's a bug. It should show the version of Qt that is running, like the About Qt... menu does.

I'll raise an issue for it.