D18245: [DrKonqi] Create QApplication in a scope to fix possible deadlock

[Christoph Roick]

croick added a comment.


  The problem does not seem to be specific to DrKonqi. Once DrKonqi and KDevelop are stuck, any Qt program may have problems starting or quitting. A minimal example
  
    #include <QApplication>
    #include <QWidget>
    
    int main(int argc, char **argv)
    {
        QApplication app(argc, argv);
        QWidget().show();
    
        return 0;
    }
  
  gets stuck as well (sometimes starting like below, sometimes only when quitting), as long as KDevelop was not SIGSTOPped.
  
    (gdb) info thread
      Id   Target Id                                          Frame 
    * 1    Thread 0x7ffff36a2f80 (LWP 21781) "testqt"         0x00007ffff6a116eb in brk () from /usr/lib/libc.so.6
      2    Thread 0x7ffff2346700 (LWP 21785) "QXcbEventQueue" 0x00007ffff6a0fc21 in poll () from /usr/lib/libc.so.6
      3    Thread 0x7fffe9642700 (LWP 21786) "testqt:disk$0"  0x00007ffff690bafc in pthread_cond_wait@@GLIBC_2.3.2 ()
       from /usr/lib/libpthread.so.0
    (gdb) thread apply all bt
    
    Thread 3 (Thread 0x7fffe9642700 (LWP 21786)):
    #0  0x00007ffff690bafc in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
    #1  0x00007fffe9c5ec94 in ?? () from /usr/lib/dri/i965_dri.so
    #2  0x00007fffe9c5e9b8 in ?? () from /usr/lib/dri/i965_dri.so
    #3  0x00007ffff6905a9d in start_thread () from /usr/lib/libpthread.so.0
    #4  0x00007ffff6a1ab23 in clone () from /usr/lib/libc.so.6
    
    Thread 2 (Thread 0x7ffff2346700 (LWP 21785)):
    #0  0x00007ffff6a0fc21 in poll () from /usr/lib/libc.so.6
    #1  0x00007ffff38f5630 in ?? () from /usr/lib/libxcb.so.1
    #2  0x00007ffff38f72db in xcb_wait_for_event () from /usr/lib/libxcb.so.1
    #3  0x00007ffff31f0949 in ?? () from /usr/lib/libQt5XcbQpa.so.5
    #4  0x00007ffff6ed196c in ?? () from /usr/lib/libQt5Core.so.5
    #5  0x00007ffff6905a9d in start_thread () from /usr/lib/libpthread.so.0
    #6  0x00007ffff6a1ab23 in clone () from /usr/lib/libc.so.6
    
    Thread 1 (Thread 0x7ffff36a2f80 (LWP 21781)):
    #0  0x00007ffff6a116eb in brk () from /usr/lib/libc.so.6
    #1  0x00007ffff6a117d1 in sbrk () from /usr/lib/libc.so.6
    #2  0x00007ffff69a63ed in __default_morecore () from /usr/lib/libc.so.6
    #3  0x00007ffff69a2656 in sysmalloc () from /usr/lib/libc.so.6
    #4  0x00007ffff69a3716 in _int_malloc () from /usr/lib/libc.so.6
    #5  0x00007ffff69a4ada in malloc () from /usr/lib/libc.so.6
    #6  0x00007fffeaaf3377 in ?? () from /usr/lib/libGLX_mesa.so.0
    #7  0x00007fffeaafba7b in ?? () from /usr/lib/libGLX_mesa.so.0
    #8  0x00007fffeaae7d09 in ?? () from /usr/lib/libGLX_mesa.so.0
    #9  0x00007fffeaae3335 in ?? () from /usr/lib/libGLX_mesa.so.0
    #10 0x00007fffeaae3d4d in ?? () from /usr/lib/libGLX_mesa.so.0
    #11 0x00007ffff3321f5f in ?? () from /usr/lib/qt/plugins/xcbglintegrations/libqxcb-glx-integration.so
    #12 0x00007ffff31de99a in QXcbWindow::create() () from /usr/lib/libQt5XcbQpa.so.5
    #13 0x00007ffff31c9880 in QXcbIntegration::createPlatformWindow(QWindow*) const () from /usr/lib/libQt5XcbQpa.so.5
    #14 0x00007ffff746a9d8 in QWindowPrivate::create(bool, unsigned long long) () from /usr/lib/libQt5Gui.so.5
    #15 0x00007ffff7a888d8 in QWidgetPrivate::create_sys(unsigned long long, bool, bool) () from /usr/lib/libQt5Widgets.so.5
    #16 0x00007ffff7a88f30 in QWidget::create(unsigned long long, bool, bool) () from /usr/lib/libQt5Widgets.so.5
    #17 0x00007ffff7a96596 in QWidget::setVisible(bool) () from /usr/lib/libQt5Widgets.so.5
    #18 0x0000555555555204 in main (argc=1, argv=0x7fffffffe578) at testqt.cpp:7
  
  
  
  > The commit message is nonsense. This problem has nothing to do with D-Bus. That's a red herring, because the QDBusConnection thread only exits after all open QDBusConnections close (including QDBusMessages holding them). The problem appears to be the XCB thread, stuck waiting for something, somehow, inside XCloseDisplay.
  
  So truly no DBus in this case. It really seems to be a problem with the graphics library, which could be the reason why this problem does not seem to be common.
  
  ---
  
  > The patch is innocuous. I don't see *how* it can solve anything, though, because I don;'t know what DrKonqu::cleanup does.
  
  One of the things that `DrKonqi::cleanup()` does is sending SIGCONT to the debuggee to finish it. I just checked: Not sending the signal makes DrKonqi quit entirely.
  I will add a comment in the code and change the commit message. The patch still remains a workaround though.

REPOSITORY
  R871 DrKonqi

REVISION DETAIL
  https://phabricator.kde.org/D18245

To: croick, sitter, #kdevelop
Cc: dfaure, thiago, ossi, plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20190224/d0d6d70b/attachment-0001.html>