You are not logged in.
Hi,
I have been developing a Qt6-based desktop environment for Arch, which worked beautifully until yesterday's updates.
Since then, I experience huge delays (20 seconds or more) when starting any of my programs. DBus appears largely broken as well.
For example, when I use qdbus6 to check which DBus services are registered, I get to see the expected output, but when I try to probe any of my programs (e.g. qdbus6 org.rde.rfm) the process hangs for about half a minute and then returns:
Error: org.freedesktop.DBus.Error.NoReply
Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
If I do the same with a third-party app, it works fine.
Anyone experiencing similar problems?
Offline
That sound a lot like specific to your local "Qt6-based desktop environment", did you try to recompile the binary after the update?
Sources?
Offline
Hi,
Yes of course, recompiling the project is the first thing I've done.
I've been looking into this for a while now. It's not just my code, QtCreator (the Qt IDE) has a noticeable delay on startup too, and the more I'm looking, the more baffling it becomes.
Consider this minimal test program:
main.cpp
#include <QGuiApplication>
#include <QDebug>
int main(int argc,char *argv[])
{
QGuiApplication app(argc,argv);
qDebug() << "About to execute app";
return app.exec();
}It takes about 20 seconds before the program outputs "About to execute app".
Strange, right?
Last edited by Eocene (2025-03-29 11:22:33)
Offline
printenv
strace -tt -f -o /tmp/main.strace main # for your mainp.cpp testcaseThen please elaborate on
If I do the same with a third-party app, it works fine.
what "third-party app" specifically?
Offline
In the meantime I have uninstalled qt6 completely, rebooted, and reinstalled it.
This appears to have fixed the problem partially; Qt apps now start normally, including the test app shown above, QtCreator, pcmanfm-qt, pavucontrol etc - no more delay.
So doing an strace now isn't helpful anymore, but just in case you still need my env:
ALACRITTY_LOG=/tmp/Alacritty-42879.log
ALACRITTY_SOCKET=/run/user/1000/Alacritty-wayland-1-42879.sock
ALACRITTY_WINDOW_ID=98955595478048
COLORTERM=truecolor
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
DEBUGINFOD_URLS=https://debuginfod.archlinux.org
DISPLAY=:0
DXVK_FRAME_RATE=60
DXVK_STATE_CACHE_PATH=/games/steam/shader_cache/dxvk
ENABLE_GAMESCOPE_WSI=0
HOME=/home/eocene
LANG=en_US.UTF-8
LIBVA_DRIVER_NAME=radeonsi
LOGNAME=eocene
MAIL=/var/spool/mail/eocene
MESA_SHADER_CACHE_DIR=/games/steam/shader_cache/mesa
MOTD_SHOWN=pam
OLDPWD=/home/eocene
PATH=/data/scripts:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/data/scripts
PWD=/home/eocene
QML_IMPORT_PATH=/data/rde
RDE_DIR=/data/rde
RWAY_SOCKET=/tmp/rway.socket
SHELL=/bin/zsh
SHLVL=2
TERM=alacritty
USER=eocene
VDPAU_DRIVER=radeonsi
WAYFIRE_CONFIG_FILE=/home/eocene/.config/rde/wayfire.ini
WAYFIRE_SOCKET=/run/user/1000/wayfire-wayland-1-.socket
WAYLAND_DISPLAY=wayland-1
WINDOWID=98955595478048
WINEDEBUG=-all
XCURSOR_SIZE=24
XCURSOR_THEME=NeoAlien-dark
XDG_RUNTIME_DIR=/run/user/1000
XDG_SEAT=seat0
XDG_SESSION_CLASS=user
XDG_SESSION_ID=10
XDG_SESSION_TYPE=wayland
XDG_VTNR=2
_=/usr/bin/printenv
_JAVA_AWT_WM_NONREPARENTING=1The DBus problem still persists, though, and I rely on it, heavily.
For example this line:
QDBusInterface* interface=new QDBusInterface("org.rde.ai","/org/rde/ai/Mouth","org.rde.ai.mouth",QDBusConnection::sessionBus(),this);still causes a huge delay.
Using qdbus6 to probe VLC (org.mpris.MediaPlayer2.vlc) gives the expected output, but probing mine (org.mpris.MediaPlayer2.rmp) causes the program to freeze.
Doing this:
m_watcher=new QDBusServiceWatcher("org.mpris.MediaPlayer2*",QDBusConnection::sessionBus(),QDBusServiceWatcher::WatchForOwnerChange,this);
connect(m_watcher,&QDBusServiceWatcher::serviceRegistered,[=](const QString& service){
qDebug() << "New service registered!";
}... is also broken. It is supposed to fire a signal whenever a new media player is launched. The signal is not fired anymore.
I can't help but conclude that the qt6 updates from yesterday broke DBus support.
Last edited by Eocene (2025-03-29 11:19:57)
Offline
Please use [code][/code] tags. Edit your post in this regard.
Feel free to test a Qt downgrade to 6.8.2, but if your client is the only one that stalls at dbus access, we might want to take a look at the specific code.
Offline
Okay, edited.
After a reboot, the delay problem came back again.
So trying this:
strace -tt -f -o /tmp/main.strace rjournaldoes not show any output that doesn't come from rjournal.
I'm stumped.
What is the best way to downgrade to Qt 6.2?
Offline
https://wiki.archlinux.org/title/Arch_Linux_Archive
But also send nud… the strace.
Of course it'll only show output from the invoked process, the $60.000 question is where it stalls (doing what)
Offline
Been looking into it some more. All the stalling appears to be related to DBus.
Qt uses an environment variable (QT_QPA_PLATFORMTHEME) that points to a plugin which provides icon and cursorthemes, fonts etc. My DE uses a custom one (as DEs are supposed to do), but it also relies on DBus for a number of things. So, whenever a Qt program is started, it'll invoke an instance of said plugin first, and get hung up while the plugin tries to do DBus stuff.
Another cause was that many of my programs hook into a DBus service that provides them with text-to-speech and speech-to-text services. So, not running that service AND switching to another Qt platform theme plugin (e.g. qt6ct) fixes the stalls.
So all the problems I've been having since the update to 6.8.3 are side effects from DBus not working properly anymore. If anything, this taught me to robustify some aspects to my code.
So everything just boils down to DBus being troublesome. I'm going to not downgrade just yet though. I have some time this afternoon, I'll write a DBus testing tool and try to pinpoint the cause.
Thanks for your advice so far.
Offline
I'll write a DBus testing tool and try to pinpoint the cause.
If the problem is limited to your QPA, the cause is your QPA - the trigger could be as obscure as some unrelated code change in Qt exposing a race condition or whatever.
If you want informed comments by anyone about what could be problematic w/ your code, you'll have to link it here.
All can tell you is that you want to debug your code, not "dbus".
Offline
Just wanted to add that the problem has been fixed.
Apparently, Qt 6.8.3 now requires an actual object to be registered for DBus, and not just a service name anymore. I did the latter to enforce single instances.
So, fixing it is as simple as doing something like:
#define Service "org.rde.test"
#include <QDBusConnection>
#include <QCoreApplication>
int main(int argc,char *argv[])
{
QCoreApplication app(argc,argv);
QDBusConnection session=QDBusConnection::sessionBus();
if(!session.isConnected()){
qCritical() << "Cannot connect to system bus!";
return 1;
}
if(!session.registerService(Service)){
qCritical() << "Failed to register service" << Service;
return 2;
}
if(!session.registerObject("/",&app)){
qCritical() << "Failed to register object /";
return 3;
}
return app.exec();
}Registering the QCoreApplication instance as the DBus object did the trick.
Thanks for your patience, problem solved!
Last edited by Eocene (2025-04-02 08:27:05)
Offline