https://bugs.kde.org/show_bug.cgi?id=383655
--- Comment #5 from Emmanuel Lepage Vallée <elv1...@gmail.com> ---
Umm, it might be another bug on your system. It's very strange/problematic
because the backtrace is totally inconclusive (as you already noticed).
On my system (still locked to Qt 5.7 as it is the minimum version supported by
Ring-KDE), The Qt bug from above is the *only* problem I can see when quitting.
Here's a simplified backtrace when Ring-KDE is complited with `-ggdb` and it's
debug symbols intact:
Application: ring-kde (ring-kde), signal: Segmentation fault
Using host libthread_db library "/lib64/libthread_db.so.1".
[Current thread is 1 (Thread 0x7f1190357740 (LWP 2622))]
Thread 2 (Thread 0x7f118731c700 (LWP 2635)):
[KCrash Handler]
#6 0x000000003e746e69 in ?? ()
#7 0x00007f1199eaa080 in QObject::disconnect(QObject const*, char const*,
QObject const*, char const*) () from /usr/lib64/libQt5Core.so.5
#8 0x00007f119f7e8d50 in QDBusConnectionPrivate::closeConnection() () from
/usr/lib64/libQt5DBus.so.5
#9 0x00007f119f7d5916 in QDBusConnectionManager::run() () from
/usr/lib64/libQt5DBus.so.5
#10 0x00007f1199cebffc in QThreadPrivate::start(void*) () from
/usr/lib64/libQt5Core.so.5
#11 0x00007f119dda84a4 in start_thread () from /lib64/libpthread.so.0
#12 0x00007f119907870f in clone () from /lib64/libc.so.6
Thread 1 (Thread 0x7f1190357740 (LWP 2622)):
#0 0x00007f119ddae20f in pthread_cond_wait () from /lib64/libpthread.so.0
#1 0x00007f1199cec64a in QWaitCondition::wait(QMutex*, unsigned long) () from
/usr/lib64/libQt5Core.so.5
#2 0x00007f1199cebc26 in QThread::wait(unsigned long) () from
/usr/lib64/libQt5Core.so.5
#3 0x00007f119f7d56a6 in QDBusConnectionManager::~QDBusConnectionManager() ()
from /usr/lib64/libQt5DBus.so.5
#4 0x00007f119f7d5739 in (anonymous
namespace)::Q_QGS__q_manager::innerFunction()::Holder::~Holder() () from
/usr/lib64/libQt5DBus.so.5
#5 0x00007f1198fc5b80 in __run_exit_handlers () from /lib64/libc.so.6
#6 0x00007f1198fc5bda in exit () from /lib64/libc.so.6
#7 0x00007f1198fb02c7 in __libc_start_main () from /lib64/libc.so.6
#8 0x000000000046adfa in _start ()
If I mitigate that one, it quits cleanly (without memory leaks and in an
orderly fashion).
The backtrace you report above could have been caused by this issue as it could
have trashed the heap and caused random backtraces unrelated to Ring-KDE.
However, that theory goes down the hole if you have Qt 5.9.1... I got a
Dockerfile for Arch to test the build, but it doesn't help with this issue as
it is clearly a bug *in something else* that leaks into Ring-KDE and cause it
to crash. I will need to install a full Virtual Machine and investigate. It
still worth understanding/fixing even if it's not in Ring-KDE itself, but as
Arch have terrible support for debug symbols, it wont be easy...
One thing I would appreciate if you could try is (in a terminal):
export QMLSCENE_DEVICE=softwarecontext
QMLSCENE_DEVICE=softwarecontext ring-kde
before executing Ring-KDE. That should help detect if the bug is in the video
driver. If it is, there's nothing I can do. I hope it's not, as having a crashy
3.0 release on system similar to use would be catastrophic...
If that doesn't work, the next step (assuming I can't reproduce) will be using
valgrind on your system. Are you familiar with valgrind?
--
You are receiving this mail because:
You are watching all bug changes.
