Qt Forum

    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Unsolved

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

    General and Desktop
    5
    25
    417
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • JonB
      JonB @SGaist last edited by 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?

      1 Reply Last reply Reply Quote 0
      • SGaist
        SGaist Lifetime Qt Champion last edited by

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

        Interested in AI ? www.idiap.ch
        Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

        1 Reply Last reply Reply Quote 0
        • JonB
          JonB @SGaist last edited by 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 1 Reply Last reply Reply Quote 0
          • J.Hilk
            J.Hilk Moderators @JonB last edited by

            @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

            Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct

            Qt Needs YOUR vote: https://bugreports.qt.io/browse/QTQAINFRA-4121


            Q: What's that?
            A: It's blue light.
            Q: What does it do?
            A: It turns blue.

            JonB 1 Reply Last reply Reply Quote 0
            • JonB
              JonB @J.Hilk last edited by

              @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 1 Reply Last reply Reply Quote 0
              • J.Hilk
                J.Hilk Moderators @JonB last edited by

                @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 😔

                Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct

                Qt Needs YOUR vote: https://bugreports.qt.io/browse/QTQAINFRA-4121


                Q: What's that?
                A: It's blue light.
                Q: What does it do?
                A: It turns blue.

                1 Reply Last reply Reply Quote 1
                • JonB
                  JonB last edited by 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...

                  1 Reply Last reply Reply Quote 0
                  • JonB
                    JonB last edited by 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?

                    1 Reply Last reply Reply Quote 0
                    • SGaist
                      SGaist Lifetime Qt Champion last edited by

                      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.

                      Interested in AI ? www.idiap.ch
                      Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

                      1 Reply Last reply Reply Quote 0
                      • I
                        iynaur last edited by iynaur

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

                        I 1 Reply Last reply Reply Quote 0
                        • I
                          iynaur @iynaur last edited by

                          @iynaur And vs code too.

                          I 1 Reply Last reply Reply Quote 0
                          • Christian Ehrlicher
                            Christian Ehrlicher Lifetime Qt Champion last edited by

                            Feel free to provide a patch for it...

                            Qt has to stay free or it will die.

                            JonB 1 Reply Last reply Reply Quote 0
                            • JonB
                              JonB @Christian Ehrlicher last edited by 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! :)

                              1 Reply Last reply Reply Quote 0
                              • I
                                iynaur @iynaur last edited by iynaur

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

                                1 Reply Last reply Reply Quote 1
                                • Christian Ehrlicher
                                  Christian Ehrlicher Lifetime Qt Champion last edited by

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

                                  Qt has to stay free or it will die.

                                  JonB 1 Reply Last reply Reply Quote 0
                                  • JonB
                                    JonB @Christian Ehrlicher last edited by 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.

                                    I 1 Reply Last reply Reply Quote 0
                                    • I
                                      iynaur @JonB last edited by

                                      @JonB You can try debug with -platform wayland

                                      JonB 1 Reply Last reply Reply Quote 0
                                      • JonB
                                        JonB @iynaur last edited by

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

                                        I 1 Reply Last reply Reply Quote 0
                                        • I
                                          iynaur @JonB last edited by

                                          @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 2 Replies Last reply Reply Quote 1
                                          • JonB
                                            JonB @iynaur last edited by 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.)

                                            1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post