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

SGaist

So you may found something, using a remote session and having only started Qt Creator 4.13.3 it does indeed block all interactions once the "Signal Received" dialog appears.

I have not found anything suspicious in the logs. However, one thing I could observe is that there seems to be two dialogs appearing in quick succession but I could not see the first one, only the "Signal Received".

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

Are you Linux? I think actually you are macOS? Could you just tell me what happens to you if you try this short code with a breakpoint/assert in your environment, do you seize up or not?

I have worked with/on Qt on many platforms and even embedded ones when cross-compilation was not yet the thing it is nowadays :-)

JonB

@SGaist
Here is a screenshot of the VM taken from the Windows host:
VirtualBox_Ubuntu 20.04_09_12_2020_13_02_23.png

You can even see where it has hit the breakpoint in the debugger, and the output of aSlot message in Application Output from previous line. If you were in front of it, you can even see the line cursor flashing on the source line it is on. Nothing on the machine has actually "seized up/crashed", it's all just as it should be. The problem is that Popup window with Click to invoked slot on it. That is a modal, up-front window, and it is because of this that you cannot interact with anything, anywhere on the desktop.

When I Ctrl+Alt+F1 to get a new login window from the VM (effectively the same as your ssh), and do my ps es, it's as it should be, for the app and for gdb and for Creator. If I pkill -9 theApp, or kill the gdb, or kill the Creator, then when I'm done and go back to the desktop via Ctrl+Alt+F3 the desktop has regained normal control, because the necessary process was killed.

If I put _popup->hide() on the line above the breakpoint, that popup window goes away when the break is hit and all is well. But that's not a solution for debugging, a breakpoint could be anywhere in code....

I am Ubuntu 20.04, GNOME desktop, gcc 9.3.0, gdb 9.2, Creator 4.11.0, Qt 5.12. However, over the years I have had different versions of all of these and (so far as I do recall) this has always been a problem. I have given up debugging when I have any visible Popup window, which is much of the time in current application, and I am now fed up not being able to debug...! :(

Either the desktop windowing system has (somehow) to be told to behave differently, or Qt Creator has to know about this and take some action when hitting a breakpoint etc. to "free" the modality and allow the user to continue?

J.Hilk

@JonB
thats super odd, the popup shouldn't grab the input from the whole windowing system, but only from your application, which should be a different process to QtCreator!

Can you upload that basic example ?
Would love to test it myself

JonB

@J-Hilk said in Qt::Popup window in debugger seizes up whole windowing system:

thats super odd, the popup shouldn't grab the input from the whole windowing system, but only from your application, which should be a different process to QtCreator!

Yeah, well, like I say, similar used to happen under Windows for a combobox's dropdown getting "frozen" on-screen when a break hit, cannot interact with desktop because of that, cannot close it because at a break in the debugger. => Reboot Windows! Did it for years :( But now I'm Linux I want better!

Can you upload that basic example ?

? I pasted the 30-odd lines of code in my first post above, that's all you have to try? Am I not understanding?

J.Hilk

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

I pasted the 30-odd lines of code in my first post above, that's all you have to try? Am I not understanding?

sorry didn't see it 😔

JonB

@SGaist , @J-Hilk , @whoever
We can eliminate the issue from being in a slot on the Popup window. At the end of my AWidget constructor, get rid of the connect() and just show the popup window, followed by a breakpoint/assert/other error:

        // put a button on this widget, connect button's click to show the popup widget
        _btn = new QPushButton("Click to open popup");
        layout()->addWidget(_btn);
//        connect(_btn, &QPushButton::clicked, _popup, &QWidget::show);
        _popup->show();
        Q_ASSERT(false);
    }

Because the Popup is shown, this "freezes" on the Q_ASSERT() line. You see the popup window on the desktop (though without content visible), and that's enough to exhibit the problem.

EDIT
Because of this I can reduce the problem to just the following 5 lines:

int main(int argc, char *argv[])
{
    QApplication a(argc, argv);

    QWidget popup(nullptr, Qt::Popup);  // the `Qt::Popup` flag is what causes the problem
    popup.show();
    Q_ASSERT(false);

    return a.exec();
}

You (I) get to see that a Popup has come up, and the desktop is dead when it hits the Q_ASSERT or you put a breakpoint on that line...

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!