Bugzilla – Bug 482749
yast2 modules do not work with Qt 4.5.0
Last modified: 2009-10-26 20:47:25 UTC
Created attachment 277591 [details] y2logs I updated Qt to 4.5.0 on from the KDE:Qt repository and yast2 Qt stopped working (ncurses UI is OK). When I run Yast control center and try launching random modules, yast changes cursor to busy, after 2 seconds it is back to default, but no window appears. When I rust module directly from command-line, no windows are shown, but the commandline is stuck and I have to break with Ctrl+C. [root@leira 0 ~] /sbin/yast2 sw_single ^CYaST got signal 2 at YCP file Wizard.ycp:691 [root@leira 130 ~] /sbin/yast2 timezone ^CYaST got signal 2 at YCP file Wizard.ycp:36 [root@leira 130 ~] /sbin/yast2 sw_single ^CYaST got signal 2 at YCP file Wizard.ycp:691 [root@leira 130 ~] /sbin/yast2 nfs_server ^CYaST got signal 2 at YCP file Popup.ycp:640 [root@leira 130 ~] /sbin/yast2 nfs_server ^CYaST got signal 2 at YCP file Popup.ycp:640 [root@leira 130 ~] /sbin/yast2 timezone ^CYaST got signal 2 at YCP file Wizard.ycp:36 The problem is always at the same lines, where some Qt calls are performed (I suppose).
There seems to be nothing interesting in the logs. Please retry with Y2DEBUG=1 set.
Created attachment 277630 [details] new y2logs (with Y2DEBUG)
*** Bug 483209 has been marked as a duplicate of this bug. ***
This happens with the installed package "yast2-qt-pkg-2.16.48-0.2". If I downgrade to "yast2-qt-pkg-2.16.46-4.1", it works.
I do not have this problem on factory, which uses qt 4.5 too.
This might be fixed in newer YaST packages, but the ones shipped with 11.1 do not work. (That's why it was originally reported against 11.1 product).
Well, is this something worth solving? It is quite likely that YaST built against Qt4.4 will not work with newer version of the library if its binary API has changed. I think that one should rebuild yast2-qt + yast2-qt-pkg against Qt4.5.
If you think that API has changed and the issue is not worth to solve, then feel free to close the bug. I can stick to ncurses frontend.
Qt is supposed to be binary compatible, and in fact we need it to be so so we can upgrade to 4.5 in SLE11SP1, so we should not ignore this crash.
does it work if you rebuild yast2-qt against KDE:Qt? that should be easy to check.
Stephan binner told me that it is not enough. so there should be a source change in yast-* that fixes the issue?
Found as work-around that adding a /root/.config/Trolltech.conf with [Qt] style=Cleanlooks prevents any hangs so it rather looks like a binary compatibility problem with styles, which results in the unconfigured ("Desktop Settings (default)") default in against Qt 4.4 compiled oxygen.so.
@Stephan Binner: Tried this, unfortunately with no success :-(.
(In reply to comment #12) > Found as work-around ... I can confirm that this workaround works for me, despite what previous comments says.
It's also reproducible with http://download.opensuse.org/repositories/KDE:/Medias/images/iso/KDE4-UNSTABLE-Live.i686-1.2.65-Build4.1.iso It hangs in #0 0xffffe422 in __kernel_vsyscall () #1 0xb7dcbc35 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0xb61f2df2 in QMutexPrivate::wait (this=0x8e46550, timeout=-1) at thread/qmutex_unix.cpp:80 #3 0xb61ee37a in QMutex::lock (this=0x8e3c530) at thread/qmutex.cpp:207 #4 0xb45d001d in mutex_lock (mutex=0x8e3c530) at qdbusthread.cpp:69 #5 0xb7c15d7f in ?? () from /lib/libdbus-1.so.3 #6 0xb7bfcdad in ?? () from /lib/libdbus-1.so.3 #7 0xb7c01598 in ?? () from /lib/libdbus-1.so.3 #8 0xb7c0376d in ?? () from /lib/libdbus-1.so.3 #9 0xb7c10a81 in dbus_pending_call_block () from /lib/libdbus-1.so.3 #10 0xb7c027fa in dbus_connection_send_with_reply_and_block () from /lib/libdbus-1.so.3 #11 0xb7bfd18e in dbus_bus_register () from /lib/libdbus-1.so.3 #12 0xb7bfd639 in ?? () from /lib/libdbus-1.so.3 #13 0xb459f443 in QDBusConnection::connectToBus (type=QDBusConnection::SessionBus, name=@0xb5495008) at ./qdbus_symbols_p.h:99 #14 0xb459f5d6 in _q_sessionBus () at qdbusconnection.cpp:953 #15 0xb459f74f in QDBusConnection::sessionBus () at qdbusconnection.cpp:967 #16 0xb4c3bbbd in ?? () from /usr/lib/kde4/plugins/styles/oxygen.so #17 0xb4c3f77e in ?? () from /usr/lib/kde4/plugins/styles/oxygen.so #18 0xb5c1391f in QStyleFactory::create(QString const&) () from /usr/lib/libQtGui.so.4 #19 0xb59168c8 in QApplication::style() () from /usr/lib/libQtGui.so.4 #20 0xb5981b78 in ?? () from /usr/lib/libQtGui.so.4 #21 0xb598bc9b in ?? () from /usr/lib/libQtGui.so.4 #22 0xb5916c53 in QApplicationPrivate::construct(_XDisplay*, unsigned long, unsigned long) () from /usr/lib/libQtGui.so.4 #23 0xb5917a63 in QApplication::QApplication(int&, char**, int) () from /usr/lib/libQtGui.so.4 #24 0xb64a02be in YQUI::initUI() () from /usr/lib/YaST2/plugin/libpy2qt.so.2 #25 0xb64a12df in YQUI::idleLoop(int) () from /usr/lib/YaST2/plugin/libpy2qt.so.2 #26 0xb7301dd7 in YUI::uiThreadMainLoop() () from /usr/lib/libyui.so.3 #27 0xb73020e1 in start_ui_thread(void*) () from /usr/lib/libyui.so.3 #28 0xb7dc81b5 in start_thread () from /lib/libpthread.so.0 #29 0xb7a3838e in clone () from /lib/libc.so.6
Is there a session bus running for root at that point?
so the problem is that the widget style does a blocking dbus call. unset DBUS_SESSION_BUS_ADDRESS fixes the issue. I didn't know that this was a new bug, I ran into it as well before. I'll try to add a fix.
Still experiencing with installed Milestone 1 KDE Live-CD.
*** Bug 509626 has been marked as a duplicate of this bug. ***
This is also broken on 11.0 using KDE4 Factory (4.3 beta) and qt 4.5. I have the same error message as described in bug #509626 (marked as a duplicate of this bug). My version of yast2-qt-pkg is 2.17.3-19.1.
Created attachment 296213 [details] y2log (with Y2DEBUG=1) Following up, here's a capture of my y2log with Y2DEBUG=1. Looks like it can't load LibQtGui.so.4
THE SOLUTION: The bug with the 1-click-install for kde43beta1 is just the failure to add factory-oss and upgrade yast when the qt45 libs are pulled in. So: zypper ar http://download.opensuse.org/factory/repo/oss/ factory-oss zypper ref -r factory-oss zypper in -r factory-oss yast2 BINGO! Problem solved. Yast SW Management now seems to be OK. I have loaded and updated numerous packages after this fix and all is well.
Still doesn't work for me, even after following the suggestion in C22 - same error message when trying to load any Yast2 module (the core gui loads ok - always has, but can't load any modules to do anything).
Now fixed :-). I had installed the qt 4.5.2 devel snapshots and that was one step too far. After downgrading to qt 4.5.1 Yast2 is now back to its normal working state again.
It still happens to me with the latest libqt4-4.5.1-2.6 from factory. How did you guys get it to work? :O) Must be a matter of several factors, not just qt then. Dirk, what's the status?
*** Bug 504595 has been marked as a duplicate of this bug. ***
It's SHIP_STOPPER+ by now.
*** Bug 533712 has been marked as a duplicate of this bug. ***
*** Bug 540747 has been marked as a duplicate of this bug. ***
you can reproduce it with just su; qdbus #0 0xffffe430 in __kernel_vsyscall () #1 0xb793dd95 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0xb7b5d27c in pthread_cond_wait () from /lib/libc.so.6 #3 0xb7d3fce4 in QMutexPrivate::wait (this=0x806f7b8, timeout=-1) at thread/qmutex_unix.cpp:80 #4 0xb7d3b2d2 in QMutex::lock (this=0x8066988) at thread/qmutex.cpp:207 #5 0xb7fb0d3b in mutex_lock (mutex=0x8066988) at qdbusthread.cpp:69 #6 0xb7a5dcaf in _dbus_mutex_lock (mutex=0xfffffe00) at dbus-threads.c:150 #7 0xb7a4424e in _dbus_bus_notify_shared_connection_disconnected_unlocked (connection=0x8071a28) at dbus-bus.c:405 #8 0xb7a48ba0 in notify_disconnected_unlocked (connection=<value optimized out>) at dbus-connection.c:3967 #9 _dbus_connection_get_dispatch_status_unlocked (connection=<value optimized out>) at dbus-connection.c:4044 #10 0xb7a4afa4 in _dbus_connection_block_pending_call (pending=0x80715c8) at dbus-connection.c:2295 #11 0xb7a58d1f in dbus_pending_call_block (pending=0xfffffe00) at dbus-pending-call.c:705 #12 0xb7a4a5b3 in dbus_connection_send_with_reply_and_block (connection=0x8071a28, message=0x8071e68, timeout_milliseconds=-1, error=0xbfef5868) at dbus-connection.c:3356 #13 0xb7a4464a in dbus_bus_register (connection=0x8071a28, error=0xbfef5868) at dbus-bus.c:698 #14 0xb7a44adb in internal_bus_get (type=DBUS_BUS_SESSION, private=<value optimized out>, error=0xbfef5868) at dbus-bus.c:491 #15 0xb7f8009b in q_dbus_bus_get_private (error=<value optimized out>, type=<value optimized out>) at ./qdbus_symbols_p.h:99 #16 QDBusConnection::connectToBus (error=<value optimized out>, type=<value optimized out>) at qdbusconnection.cpp:335 #17 0xb7f80234 in QDBusDefaultConnection (name=<value optimized out>, type=<value optimized out>, ---Type <return> to continue, or q <return> to quit--- this=<value optimized out>) at qdbusconnection.cpp:953 #18 _q_sessionBus (name=<value optimized out>, type=<value optimized out>, this=<value optimized out>) at qdbusconnection.cpp:960 #19 0xb7f803af in QDBusConnection::sessionBus () at qdbusconnection.cpp:967 #20 0x08050aeb in main (argc=1, argv=0xbfef5b64) at qdbus.cpp:417
Dirk, can we have the fix for RC1?
submission today?
as in _NOW_, yes :)
update submitted (sr22276), only compile tested sofar.
Could a fix for this be backported to 11.0? I still have to use the workaround from comment #4 on my 11.0 system.
the fix is in KDE:Qt repo in the buildservice, feel free to grab it from there.