Important: Please read the Qt Code of Conduct -

Random occasional freezing when showing a new widget

  • My application has one main window (inherits from QMainWindow). The main window is parent to a QTabWidget, which acts as a sort of dialog that shows up when the user clicks a toolbar button on the main window, and hides when its 'Close' button is clicked. In addition, the main window has another toolbar button, which when clicked, calls exec() on a QDialog. While developing the app, I have noticed that once every 40 times or so, clicking one of the two buttons I have mentioned causes an empty widget to appear, but instead of the intended view being drawn, everything freezes. When I click the 'Close' button on the main window, my OS tells me that the application has stopped responding. There is never any way to recover from crashes like this, and I am usually forced to kill the app and restart.

    The vexing thing about all this is that I cannot reproduce the crashes at will. They are impossible to predict, and often catch me off-guard. I am using Qt Creator. Nothing helpful is printed in the Creator console when the crashes occur.

    Has anyone run into such an issue? How do I debug what is happening?

    Btw I am running Ubuntu 14.04.2 LTS, and my Qt Version is 5.4

  • Moderators

    If you can get it to happen again and be ready you can quickly break into it with a debugger and see what is going on/causing the freeze. If you post that backtrace we could probably help more.

    So, once your app is running, do:

    $ ps -ef | grep myapp
    mike       656     1  0 20:14 ?        00:00:02 /usr/bin/konsole
    mike      1440   784  0 20:36 pts/2    00:00:00 grep --color=auto konsole

    That first number is your process number. So If I wanted to break into my konsole I would use 656.

    Then do:

    $ gdb konsole 656
    (gdb) bt
    #0  0x00007f293d770c8d in poll () from /lib64/
    #1  0x00007f2934511734 in ?? () from /usr/lib64/
    #2  0x00007f293451183c in g_main_context_iteration () from /usr/lib64/
    #3  0x00007f293a40d12c in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>)
        () from /usr/lib64/
    #4  0x00007f293a3b19db in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) ()
       from /usr/lib64/
    #5  0x00007f293a3b942f in QCoreApplication::exec() () from /usr/lib64/
    #6  0x00007f293da4b32d in kdemain () from /usr/lib64/
    #7  0x00007f293d6b3aa5 in __libc_start_main () from /lib64/
    #8  0x00000000004007ae in _start ()
    (gdb) quit
    A debugging session is active.
            Inferior 1 [process 656] will be detached.
    Quit anyway? (y or n) y
    Detaching from program: /usr/bin/konsole, process 656

    Now as you can see that will give you a backtrace of what is going on during the "freeze" or crash. Should help out quite a bit.

  • Thanks ambershark. I managed to attach to a running process right after a crash.

    #0  pthread_cond_wait@@GLIBC_2.3.2 ()
        at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
    #1  0x00007f1ba3bf1b03 in QWaitCondition::wait(QMutex*, unsigned long) ()
       from /opt/Qt/5.4/gcc_64/lib/
    #2  0x00007f1ba3bea277 in QReadWriteLock::lockForRead() ()
       from /opt/Qt/5.4/gcc_64/lib/
    #3  0x00007f1b9bf5ee4e in ?? () from /opt/Qt/5.4/gcc_64/plugins/platforms/../../lib/
    #4  0x00007f1b9bf61d71 in ?? () from /opt/Qt/5.4/gcc_64/plugins/platforms/../../lib/
    #5  0x00007f1b9bf64e54 in ?? () from /opt/Qt/5.4/gcc_64/plugins/platforms/../../lib/
    #6  0x00007f1b904159d6 in dbus_connection_dispatch () from /lib/x86_64-linux-gnu/
    #7  0x00007f1b9bf579f5 in ?? () from /opt/Qt/5.4/gcc_64/plugins/platforms/../../lib/
    #8  0x00007f1b9bfa78f5 in ?? () from /opt/Qt/5.4/gcc_64/plugins/platforms/../../lib/
    #9  0x00007f1ba3e5a326 in QObject::event(QEvent*) () from /opt/Qt/5.4/gcc_64/lib/
    #10 0x00007f1ba510b8f4 in QApplicationPrivate::notify_helper(QObject*, QEvent*) ()
       from /opt/Qt/5.4/gcc_64/lib/
    #11 0x00007f1ba510f506 in QApplication::notify(QObject*, QEvent*) ()
       from /opt/Qt/5.4/gcc_64/lib/
    #12 0x00007f1ba3e25c84 in QCoreApplication::notifyInternal(QObject*, QEvent*) ()
       from /opt/Qt/5.4/gcc_64/lib/
    #13 0x00007f1ba3e28868 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) ()
       from /opt/Qt/5.4/gcc_64/lib/
    #14 0x00007f1ba3e80123 in ?? () from /opt/Qt/5.4/gcc_64/lib/
    #15 0x00007f1ba283be04 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/
    #16 0x00007f1ba283c048 in ?? () from /lib/x86_64-linux-gnu/
    #17 0x00007f1ba283c0ec in g_main_context_iteration () from /lib/x86_64-linux-gnu/
    #18 0x00007f1ba3e80554 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>)
        () from /opt/Qt/5.4/gcc_64/lib/
    #19 0x00007f1ba3e23eab in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) ()
       from /opt/Qt/5.4/gcc_64/lib/
    #20 0x00007f1ba530a2ed in QDialog::exec() () from /opt/Qt/5.4/gcc_64/lib/
    #21 0x0000000000425fe4 in MainWindow::AddNewDownload() ()
    #22 0x00007f1ba3e57e7a in QMetaObject::activate(QObject*, int, int, void**) ()
       from /opt/Qt/5.4/gcc_64/lib/
    #23 0x00007f1ba50fee52 in QAction::triggered(bool) () from /opt/Qt/5.4/gcc_64/lib/
    #24 0x00007f1ba5100c77 in QAction::activate(QAction::ActionEvent) ()
       from /opt/Qt/5.4/gcc_64/lib/
    #25 0x00007f1ba520b0b5 in ?? () from /opt/Qt/5.4/gcc_64/lib/
    #26 0x00007f1ba520b374 in QAbstractButton::mouseReleaseEvent(QMouseEvent*) ()
       from /opt/Qt/5.4/gcc_64/lib/
    #27 0x00007f1ba52cf89a in QToolButton::mouseReleaseEvent(QMouseEvent*) ()
       from /opt/Qt/5.4/gcc_64/lib/
    #28 0x00007f1ba514723c in QWidget::event(QEvent*) () from /opt/Qt/5.4/gcc_64/lib/
    #29 0x00007f1ba52d0730 in QToolButton::event(QEvent*) ()
       from /opt/Qt/5.4/gcc_64/lib/
    #30 0x00007f1ba510b8f4 in QApplicationPrivate::notify_helper(QObject*, QEvent*) ()
       from /opt/Qt/5.4/gcc_64/lib/
    #31 0x00007f1ba510f071 in QApplication::notify(QObject*, QEvent*) ()
       from /opt/Qt/5.4/gcc_64/lib/
    #32 0x00007f1ba3e25c84 in QCoreApplication::notifyInternal(QObject*, QEvent*) ()
       from /opt/Qt/5.4/gcc_64/lib/
    #33 0x00007f1ba510df88 in QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer<QWidget>&, bool) () from /opt/Qt/5.4/gcc_64/lib/
    #34 0x00007f1ba5162387 in ?? () from /opt/Qt/5.4/gcc_64/lib/
    #35 0x00007f1ba5164e78 in ?? () from /opt/Qt/5.4/gcc_64/lib/
    ---Type <return> to continue, or q <return> to quit---

    MainWindow::AddNewDownload is the name of a private slot that launches the dialog I mentioned in the original post.

  • Moderators

    Hmm.. What window system are you using?

    The freeze is obvious though. It is waiting on a locked mutex. The question is, why is the mutex locked and what is taking so long to get it released (or timed out).

    It looks related to dbus.

    Another thing to try is using strace ./myapp. And see what messages are coming out (i.e. what system calls are being made) during the freeze. Something in dbus is causing a mutex to be locked for too long, now we just have to find out what is causing it and why.

  • Compiz is my current window manager

    The only useful information I have gleaned from ptrace so far is that my app gets stuck on a futex(0x7f403c00690c, FUTEX_WAIT_PRIVATE, 1, NULL) call. I am not using any QThreads, , and it is not obvious to me at all what my application is waiting on. It appears that displaying the dialog involves waiting on a condition from the OS, but in some cases that condition is never met and my app is never woken up.

  • @ambershark I think the presence of dbus in the backtrace only indicates that my application was trying to talk to a presumably GUI-related process. The issue may not necessarily be with dbus itself.

  • Moderators

    Do you happen to have another window manager install that you can test with just to eliminate that as a possibility? Shot in the dark there I know. :) Preferably something with Qt support like KDE, but anything will do. Gnome/fluxbox/xfce, whatever you might have laying around.

    What is weird is that the mutex is locking and not being released in any sort of timely fashion. So even if the dbus thing is a normal GUI action it is taking way too long.

    And yea I don't think it's your application locking up. It is something with Qt and Qt's threads, not with your single threaded app. It could be something with your linux/wm, or dbus as well.

    This is going to be tough to figure out.

    If you can try a new version of Qt. 5.5 just came out, maybe try that and see if the symptoms resolve themselves. If not let me know how the window manager tests go. I'm not really sure where to suggest you go from here. It doesn't sound like it is something with your application.

    If your app is easy to build (no crazy dependencies), and it isn't top secret, you could send me the code and instructions on duplicating the issue, and I can test on my linux system. I'm running gentoo/plasma5. Along those lines you could try a virtualbox (or other vm) with some other flavor of linux/kde/gnome and see if it has the same problem there.

Log in to reply