Debug or assert in Popup requires machine hard reboot!!

JonB

I am Ubuntu. I have no idea whether problem is same under Windows/Mac. Doesn't matter what version Ubuntu or what version of Qt/Creator/gdb. For a long time I've been meaning to raise this issue. It may not be a Qt-only-debugging issue, but it is a real problem.

In a word, if you put a debug breakpoint or a Q_ASSERT which will fail and hence break in the debugger in code when a popup window is shown, the whole machine's desktop/GUI will freeze up permanently, and the only thing you can do is HARD REBOOT the machine!.

I believe, but not sure, that the same thing will happen if you have a combobox showing its dropdown when you hit a break. The point being, it's any kind of "popup" window. And the problem is that you cannot interact with anything else on the machine while it's shown and you are at breakpoint. Since you cannot interact with the Creator debugger either, you cannot do anything.

I paste a small example to illustrate. It's not my best piece of coding, but it's a minimal example just to show the behaviour. It really doesn't matter how the code does it, you can roll your own, it's the principle of the behaviour.

#include <QApplication>
#include <QDebug>
#include <QPushButton>
#include <QWidget>

class PushButtonWithPopup : public QPushButton
{
public:
    QWidget _popup;
    QPushButton *_test = new QPushButton("Click to invoke slot", &_popup);

    explicit PushButtonWithPopup(const QString &text, QWidget *parent = nullptr) :
        QPushButton(text, parent)
    {
        // popup window flags (popup with no frame)
        _popup.setWindowFlags(Qt::Popup | Qt::FramelessWindowHint);

        // connect button click to execute the popup
        connect(this, &QPushButton::clicked, &_popup, &QWidget::show);

        // connect the popup's button to call a slot, where you can break
        connect(_test, &QPushButton::clicked, this, &PushButtonWithPopup::aSlot);
    }

    virtual ~PushButtonWithPopup()
    {
    }

public slots:
    void aSlot(bool)
    {
        qDebug() << "aSlot";
//        Q_ASSERT(false);
    }
};


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

    PushButtonWithPopup *btn = new PushButtonWithPopup("Click to open popup", &w);
    Q_UNUSED(btn);

    w.show();
    return a.exec();
}

When run, click the main widget's button to show the popup. Then click the popup's button to hit the slot, aSlot().

Now put a debugger breakpoint in aSlot(), or uncomment the Q_ASSERT. Be brave! Because once it hits that breakpoint, your whole desktop GUI is completely dead, and there's nowt you can do except hard-reboot the machine.... :@

What I am looking for is:

Can anyone see a "workaround", because I cannot? Sorry, but while I develop I do need breakpoints/hit asserts, and having to remember this will mean, if it happens to be hit anywhere down in code while a popup is showing, I lose the whole machine is not good, on top of course making actual debugging when inside when a popup is showing be impossible itself, regardless.
Personally I run Ubuntu in a VirtualBox under Windows (7). Does anyone know of any keypress I could click when this happens which would at least get me back to any kind of "Linux console" so that I might, e.g. kill the process or Creator? Because hard-reboot without saving anything and wait for restart is doing my head in :(

kshegunov

@JonB said in Debug or assert in Popup requires machine hard reboot!!:

Personally I run Ubuntu in a VirtualBox under Windows (7). Does anyone know of any keypress I could click when this happens which would at least get me back to any kind of "Linux console" so that I might, e.g. kill the process or Creator? Because hard-reboot without saving anything and wait for restart is doing my head in :(

Does changing the tty work (i.e. Ctrl + Alt + F1/F2/F3 etc.)? If it does switching from runlevel 5 to 3 back to 5 is going to restart the desktop environment. If it doesn't, well sorry, you're stuck between a rock and hard place, I would imagine.

JonB

@kshegunov
Oooohhhh!

Here's what I found:

Ctrl+Alt+F1: took me back to logon screen of desktop, logged in, still there, still frozen.
Ctrl+Alt+F2: did nothing(?)
Ctrl+Alt+F3: took me to new, non-desktop logon. Logged on, listed processes, killed gdb. Logged off. Then Ctrl+Alt+F1 allowed me to log back into desktop. Creator still present, but now that gdb dead I was back in control and able to use desktop! Of course, it still doesn't allow me to do any debugging of an actual issue if I need a breakpoint or it hits an assert, but at least I didn't have perform homicide on the whole of the machine! If I had had something unsaved on my desktop I would have been able to deal with it.

So thank you for this idea!

But... what is going on here?? I'm afraid I come from the days of UNIX and vt100 terminals, the days when Programmers were Programmers, and nobody was vegetarian ;-) There were no windows or function keys. What do these key combinations do? Where is this documented so I can read up? What is the relationship between the 5/3 runlevels you mention and which keys?

Christian Ehrlicher

@JonB said in Debug or assert in Popup requires machine hard reboot!!:

But... what is going on here??

You intercept in a state where the OS changes the focus from one widget to another. Since now the focus should go to your debugger it's screwed up. You should not debug such stuff on the same monitor - remote debugging is the only way to go here to not break the focus handling.

JonB

@Christian-Ehrlicher
Hi Christian. My "what's going on here" actually referred to what are the key press combinations doing, I had not heard of them, I don't know where to look them up or what they do, that's what I was asking about now?

Since my app happens to have a popup window shown a lot of the time, it can hit a breakpoint or an assert at any time nothing to do with the code for the popup window, and then I'm stuck. It's not just a case of "don't break put a breakpoint in some slot". Since I don't have another monitor/terminal etc., you are condemning me to doing remote debugging somehow forever. And since I have used one monitor/terminal for developing/debugging for the last thirty years without once having ever to do remote debugging, this is onerous....

What (I think) I would like is: when Creator IDE debugger hits break, it should take whatever actions necessary to sort out desktop focus to make it usable without freezing. For example, in the olden days of terminals the debugger was responsible for taking the terminal out of the application's current keyboard input state if it was in "raw" mode, allow user to interact with debugger with normal input handling, and then restore input state for the program each time the user went "continue" in the debugger. I'd like it to do similar with window focus. But I guess that's not going to happen....

Christian Ehrlicher

@JonB said in Debug or assert in Popup requires machine hard reboot!!:

when Creator IDE debugger hits break, it should take whatever actions necessary to sort out desktop focus to make it usable without freezing

It's an OS thing and can't be handled by the debugger (which has nothing to do with the QtCreator IDE btw). You will have exactly the same situation with the MSVC ide. And no a simple popup will not create such a situation as long as you don't set the breakpoint in the show or focusIn event of the popup.

JonB

@Christian-Ehrlicher

And No a simple popup will not create such a situation as long as you don't set the breakpoint in the show or focusIn event of the popup.

Absolutely not true, unfortunately!? My popup happens to be currently shown. I am not in a show or focus event. I have a breakpoint/assert elsewhere in my code which gets hit for whatever reason, and I get frozen. You can see my code above, where is it in your situation? I could just as well have had a break in a QTimer event and it would be frozen, as far as I know. Please comment on this?

I take the point about other environments/debuggers, hence I said "It may not be a Qt-only-debugging issue". I believe I used to see similar under Windows/VS when, say, a combobox dropdown happened to be shown.

Meanwhile: when you say remote debugging: could I have two separate instances of my VirtualBox VM running on my Windows with one monitor, and have it so one was doing the Creator debugging remotely to the other one, so I could then swap between the VMs? Do you know what I'd have to do/read to set up like this? Thanks!

kshegunov

@Christian-Ehrlicher said in Debug or assert in Popup requires machine hard reboot!!:

It's an OS thing and can't be handled by the debugger (which has nothing to do with the QtCreator IDE btw). You will have exactly the same situation with the MSVC ide. And no a simple popup will not create such a situation as long as you don't set the breakpoint in the show or focusIn event of the popup.

This shouldn't be the case. I've never hit such a limitation while debugging. I think this is simply some kind of bug/idiosyncrasy between gdb and the window manager/GUI.

@JonB said in Debug or assert in Popup requires machine hard reboot!!:

But... what is going on here??

Ctrl + Alt + Fn switches between the different terminals you have attached (ttys, or - and you're going to love this - teletypewriters). You usually have multiple of them running, as far as I can tell F1 to F7 are pretty much standard, and n in Fn is obviously the identifying ordinal.

I'm afraid I come from the days of UNIX and vt100 terminals, the days when Programmers were Programmers, and nobody was vegetarian ;-)

Yeah, we know you're old. ;P

There were no windows or function keys.

This has nothing to do with windows or function keys.

Where is this documented so I can read up?

Honestly, I have no idea. I've picked it up somewhere along the way, but I imagine linux/your distro's docs/wiki should have an explanation.

What is the relationship between the 5/3 runlevels you mention and which keys?

There's no keys for that one. init is a command line utility (I believe a shell script) that switches between the runlevels. For me on Debian there are 3 (formally 4) runlevels that are available:

0 is shutdown
1 is maintenance mode (single user, single terminal, bare bones functionality), call it the linux version of "Safe mode"
3 is multiuser no GUI mode, I get all the TTYs attached in it, but the GUI related stuff doesn't get started. Basically what one'd get if one were to be running a server/no-GUI machine
5 is multiuser + GUI, same as 3 but the window manager and all its associated daemons and such get started.

So if I want to restart the window manager:

$> su -
$> ******
$> init 3
$> init 5