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

[JonB]

@SGaist
I will shortly get back to you on all this. But I know what is happening. It is quite simply: there is a modal pop-up window visible on the desktop, when the debugger breakpoint is hit. The program cannot continue because it has broken into the debugger. And no other desktop window, neither the debugger nor anything else unrelated, can be clicked to/typed into because of the modal popup being there. That is precisely what the issue is.

Everything is "working" as it should. the app is paused, the debugger has been broken into at the right place, the desktop is still running, and so on. The problem is solely that because of the modal, up-front popup you cannot interact with anything on the desktop!

I used to have a similar-ish problem years ago developing under Windows (not Qt), whenever a combobox was dropped down and a break was hit. The combo's "choices" is a kind of modal, popup window, and same thing used to happen: locked up-front on the desktop, cannot get rid of it, cannot access anything else at all on desktop, reboot the PC. At some point either Windows behaviour or VS debugger changed to handle it, thankfully --- or maybe it never did! I tried a QCombobox for same problem here, to my surprise that does work OK when break (dropdown gets dismissed or whatever), but not for Qt::Popup....

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?

[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:

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.)