Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-97654

Wayland client crashes with error The Wayland connection broke. Did the Wayland compositor die?

    XMLWordPrintable

Details

    • Bug
    • Resolution: Incomplete
    • P1: Critical
    • None
    • 5.12.10, 5.15.5
    • QPA: Wayland
    • None
    • Linux/Wayland

    Description

      Navigation app crashes during HMI switching pages with different navigation widgets. HMI is a wayland server, Navigation application is a client both are  based on Qt Wayland interface.

      bt indicates a problem with Wayland client functionality:

      (gdb) bt 
      #0 __GI_raise (sig=sig@entry=6)
       at /usr/src/debug/glibc/2.25-r0/git/sysdeps/unix/sysv/linux/raise.c:51
      #1 0x0000007f79c2b610 in __GI_abort ()
       at /usr/src/debug/glibc/2.25-r0/git/stdlib/abort.c:89
      #2 0x0000007f7a081ed8 in qt_message_fatal (context=..., 
       message=<synthetic pointer>...)
       at /usr/src/debug/qtbase/5.12.10+gitAUTOINC+c919fc5f65-r0/git/src/corelib/global/qlogging.cpp:1907
      #3 QMessageLogger::fatal (this=this@entry=0x7f5715fc70, 
       msg=msg@entry=0x7f753da8a0 "The Wayland connection broke. Did the Wayland compositor die?")
       at /usr/src/debug/qtbase/5.12.10+gitAUTOINC+c919fc5f65-r0/git/src/corelib/global/qlogging.cpp:888
      #4 0x0000007f753750d0 in QtWaylandClient::QWaylandDisplay::checkError (
       this=<optimized out>)
       at /usr/src/debug/qtwayland/5.12.10+gitAUTOINC+971ed94adb-r0/git/src/client/qwaylanddisplay.cpp:187
      #5 0x0000007f75375384 in QtWaylandClient::QWaylandDisplay::dispatchQueueWhile(wl_event_queue*, std::function<bool ()>, int) (this=0x7f76d00780, 
       queue=0x7f61780c80, condition=..., timeout=timeout@entry=100)
       at /usr/src/debug/qtwayland/5.12.10+gitAUTOINC+971ed94adb-r0/git/src/client/qwaylanddisplay.cpp:238
      #6 0x0000007f75379e80 in QtWaylandClient::QWaylandWindow::waitForFrameSync (
      ---Type <return> to continue, or q <return> to quit---
       this=this@entry=0x7f61773780, timeout=timeout@entry=100)
       at /usr/src/debug/qtwayland/5.12.10+gitAUTOINC+971ed94adb-r0/git/src/client/qwaylandwindow.cpp:672
      #7 0x0000007f72a0f5b4 in QtWaylandClient::QWaylandGLContext::swapBuffers (
       this=0x7f61754c20, surface=<optimized out>)
       at /usr/src/debug/qtwayland/5.12.10+gitAUTOINC+971ed94adb-r0/git/src/hardwareintegration/client/wayland-egl/qwaylandglcontext.cpp:572
      #8 0x0000007f7a6e9400 in QOpenGLContext::swapBuffers (this=0x7f6a69e310, 
       surface=<optimized out>)
       at /usr/src/debug/qtbase/5.12.10+gitAUTOINC+c919fc5f65-r0/git/src/gui/kernel/qopenglcontext.cpp:1112
      #9 0x0000007f7cca3448 in QSGRenderThread::syncAndRender (
       this=this@entry=0x7f5ceec280)
       at /usr/src/debug/qtdeclarative/5.12.10+gitAUTOINC+36e4e9bbd4-r0/git/src/quick/scenegraph/qsgthreadedrenderloop.cpp:652
      #10 0x0000007f7cca689c in QSGRenderThread::run (this=0x7f5ceec280)
       at /usr/src/debug/qtdeclarative/5.12.10+gitAUTOINC+36e4e9bbd4-r0/git/src/quick/scenegraph/qsgthreadedrenderloop.cpp:730
      #11 0x0000007f7a0a25d8 in QThreadPrivate::start (arg=0x7f5ceec280)
       at /usr/src/debug/qtbase/5.12.10+gitAUTOINC+c919fc5f65-r0/git/src/corelib/thread/qthread_unix.cpp:361
      #12 0x0000007f79fbefb8 in start_thread (
       arg=0x7f79fe3000 <__pthread_keys+15728>)
      ---Type <return> to continue, or q <return> to quit---
       at /usr/src/debug/glibc/2.25-r0/git/nptl/pthread_create.c:458
      #13 0x0000007f79cc267c in thread_start ()
       at ../sysdeps/unix/sysv/linux/aarch64/clone.S:84

       

      I found the ticket https://bugreports.qt.io/browse/QTBUG-66997 with similar issue (the client crashed with debug output "The Wayland connection broke. Did the Wayland compositor die?")

      According to the comment in the ticket crash is happening because the client is blocking the GUI thread itself for a long time and no events will be read and the Wayland socket buffer will eventually fill up.

      Wayland protocol has been fundamentally designed based on that no message will ever be dropped, and no message will ever be re-ordered. So there is no functionality to drop events in case of client blocked. When the socket buffer fills up, the client is disconnected (closed). There is no Wayland compositor crash, only client disconnection.

      In  QTBUG-66997 the code was created by Qt to confirm this suggestion (it's not a fix, the code description: "This patch works around it by also reading from the Wayland socket on a separate thread, to make sure it doesn't overflow even when the GUI is blocked."): https://codereview.qt-project.org/c/qt/qtwayland/+/224622/

      The test was passed sussesfully with this hack. So the root cause of the issue is the client socket buffer overflow.

      The same issue was observed on Musicbrainz Picard app, it crashed during a long audio file importing. It was fixed here https://tickets.metabrainz.org/browse/PICARD-1625 by inserting additional QCoreApplication.processEvents() to make client responsive while doing long operations.

       

      1. Is this issue the same as QTBUG-66997? Since https://codereview.qt-project.org/c/qt/qtwayland/+/224622/ is "a horrible hack" will be there a fix for this issue from Qt? 
      2. Is this a real solution made by Musicbrainz Picard? could it resolve the problem in Navigation app?

      Attachments

        No reviews matched the request. Check your Options in the drop-down menu of this sections header.

        Activity

          People

            esabraha Eskil Abrahamsen Blomfeldt
            elebedeva Elena Lebedeva
            Votes:
            0 Vote for this issue
            Watchers:
            8 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Gerrit Reviews

                There are no open Gerrit changes