Qt::Popup window in debugger seizes up whole windowing system

JonB

This is still on-going...?

I was really hoping someone would try the 5-liner on Ubuntu, or perhaps any Linux with GNOME, or without? I am seeking to know whether this experience is common?

I have discovered the same lockup if I run the code from gdb in a terminal instead of from Creator.

I have discovered that if I change Qt::Popup to Qt::WindowStaysOnTopHint the seizure does not happen. I get the popup behaviour of the window being up-front. If I hit a debugger break, the window does still stay there, on top of Creator. Fair enough. But I can continue interacting with the desktop or the Creator debugger, no problem.

The problem will be related to do whatever Popup causes to happen after it has just been shown, where any mouse-click --- including elsewhere on the desktop, unrelated to the running app --- or any key press is "eaten" by the Popup window, dismissing itself. Because that never arrives in the debug-break case, the popup window remains up-front and no mouse click/key goes anywhere else.

Can someone explain what/how Qt::Popup does its next-click-to-dismiss work, especially under X11, or wherever this behaviour occurs?

SGaist

That's likely something to look in the xcb backend. These flags behave differently depending on the underlying OS as they are mapped to the corresponding platform flags.

iynaur

This problem also happened when use kdevelop. Long live this problem.

iynaur

@iynaur And vs code too.

Christian Ehrlicher

Feel free to provide a patch for it...

JonB

@Christian-Ehrlicher
I don't know where exactly to look/search for what Qt::Popup does about the next click in Qt code, and @SGaist's mention of "in the xcb backend". I don't have/compile source, so only via woboq. I think I had a look at the time, and gave up when I saw hundreds of uses of Qt::Popup. So if you happen to know either what the behaviour is (X11 for me) of exactly which part of Qt source I should be looking at, please tell! :)

iynaur

@iynaur But with -platform wayland this issue is gone! Must be xcb platform plugin issue.

Christian Ehrlicher

I already told somewhere else that 'popup' and debugging doesn't work together. You will likely get the same problems with other gui frameworks.

JonB

@Christian-Ehrlicher
Yes, and that is a nightmare for debugging, if you cannot help but have a popup and need to debug while it's on-screen. As I have found, and almost have to give up on debugging my code since a lot happens when this popup is up :(

I seem to recall in the distant past that this was an issue from e.g. Visual Studio if you had a combo box's drop down visible when you need to break, because in Windows that popup-box-of-choices is a special kind of "top-level desktop window" which blocks all input till the user does next click, and you can't access it or the debugger. Which caused us problems while developing code. I don't remember whether a later version of Windows (or VS) made this issue go away.

iynaur

@JonB You can try debug with -platform wayland

JonB

@iynaur said in Qt::Popup window in debugger seizes up whole windowing system:

@JonB You can try debug with -platform wayland

Now this is totally beyond me! "wayland" means nothing to me. All I know is I have a Ubuntu VM (VirtualBox) running on my Windows 7 host. I believe it uses X11. Maybe that is "xcb", I don't know.

In a word, are you saying I have/can try/will work using "wayland"? I cannot test atm....

iynaur

@JonB Could try this:
https://linuxconfig.org/how-to-enable-disable-wayland-on-ubuntu-20-04-desktop
and just run your app with
./yourapp -platform wayland
in terminal

JonB

@iynaur
Thank you! Will try tomorrow, if I remember....

Though there are comments to the link you reference:

I think I have followed this tutorial step by step, but I am still missing the Wayland option in the login menu…

Same here. I followed the steps but the only options I see are “Ubuntu” and “Gnome Classic”.

Note! Do not forget that the gpu drivers (nvidia, amd or intel) should allow the use of Wayland. If you have proprietary nvidia drivers uninstall them and install nouveau drivers.

(Hopefully the last one is not relevant to me.)

JonB

@iynaur , or @ anyone else who knows!
Well, I followed those instructions. Wayland was already enabled. I logged in using Wayland on Ubuntu. (Seems fine, all looked much the same as when I use X.) Did the ./yourapp -platform wayland. I get warning

Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.

so did export QT_QPA_PLATFORM=wayland and ran again. Get same warning, it didn't make any difference. I get

qt.qpa.plugin: Could not find the Qt platform plugin "wayland" in ""
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, xcb.

So I did what I tell everyone else: export QT_DEBUG_PLUGINS=1.

It reports finding the metadata for each of the mentioned available platform plugins. Final line:

QFactoryLoader::QFactoryLoader() checking directory path "/home/jon/AtH/debug/platforms" ...
qt.qpa.plugin: Could not find the Qt platform plugin "wayland" in ""

Since wayland is not listed among the Available platform plugins I presume this means I am supposed to have/install something to make Qt app run under Wayland? I do not compile Qt, I use the version (5.12) which is supplied with Ubuntu 20.04.

So, what am I supposed to do now? Am I supposed to get some Qt support for Wayland from somewhere?

Meanwhile I will do some further Googling....

UPDATE
I come across https://wiki.archlinux.org/index.php/wayland#Qt for Arch stating:

To enable Wayland support in Qt 5 or 6, install the qt5-wayland or qt6-wayland package, respectively.

So I get I need to install something. But under Ubuntu apt-get install qt5-wayland gets me E: Unable to locate package qt5-wayland, so now what...?

UPDATE2
OK, so I discover under Ubuntu it has to be

apt-get install qtwayland5

Sigh :)

OK, so now my app does run under Wayland! Yippee!!

I will soon try debugging now with Qt::Popup and see if I no longer "hang"!

Meanwhile, I don't much like the way it looks under Wayland display manager, compared to GNOME :( For one thing, the fonts look bigger, it looks horrible compared to xcb. Maybe I need to configure Wayland somewhere to alter.....

OK, I agree debugging no longer "freezes whole machine" with code Qt::Popup, which is great. But the Wayland layout/look/fonts are so horrible I cannot use this unless I can configure something somehow. Which I'm not getting from Googling? I don't even know that under Wayland app is using the default Fusion style I had under X11? Anyone know what to do to "configure" for Wayland, or is this not possible? Thanks!

iynaur

@JonB you may use wayland just for debug your app and use your app in xcb mode (xcb mode can run in wayland desktop env). unless you are debugging ui rendering related code.
i dont know how to configure wayland ui either.

JonB

@iynaur
Thanks, yes. I have to switch to that "log onto Wayland Ubuntu" to be able to use it all (I think so, anyway?), I think you're right that you can still run xcb mode for there though, but I don't much like logging in that way. I will keep it for emergency debugging. Shame, but better than nothing!

Plastic.Jesus

I know this is an old post, but some additional info:

This not only seizes up the window manager, but actually seems to have the effect of eventually seizing up the whole kernel - power-off / power-on.

I encountered this problem a few weeks ago - it is indeed easily reproducible.

System is Fedora 39, running KDE / X.

Once the debugger breaks, KDE is seized hard, as described in earlier posts. My plan was to use Ctrl+Alt+F3 to get a console login prompt from where I was planning to attempt to killall -9 gdb. I was actually able to login if I did it quickly. The echo of keystrokes was very laggy, and by the time I got a few keystrokes entered to kill the debugger, the entire kernel seems seized. Monitors go to sleep and can't ping from another computer. This seems particularly surprising as all the processes involved are running in user space, and the text terminal does not have any window manager involved.

Hopefully this might provide a clue to anyone working on a solution.

Unfortunately, this lock-up is so destructive that I gave up trying to debug Qt::Popup widgets, and am just removing that flag while debugging - or of course good old printf / qDebug.