Created attachment 91838 [details] build log from koji 3/27 Test #3: test_Html_formatting ........................***Failed 0.04 sec The X11 connection broke: Unsupported extension used (code 2) XIO: fatal IO error 6 (No such device or address) on X server ":98" after 6 requests (6 known processed) with 0 events remaining.
This issue does not show with a qt4 build.
Downstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=1080411
The Qt5 builds are OK in our CI which runs on CentOS 7.0, using multiple Qt5 versions from the corresponding git branches (5.2, 5.3 and 5.4). For a semi-recent example, check e.g. http://ci-logs.kde.flaska.net/35/435/4/check/check-kf5-qt54-gcc-el7/d2f8690/shell_output.log . Trojita itself does not request any X extensions. The test which fails in Koji simply creates a QWebView as a top-level widget, feeds the QWebView with some test-dependant HTML data (which are limited to inline CSS3, but with no JS, no images, nothing fancy). Then it asks the QWebView to select all text, and asks what is in the selection. It is hard to tell without a proper backtrace where exactly it fails, so here's a couple of blind suggestions: - Check xvfb-run's invocation. We're calling it with a bigger screen, different bit depth and an -ac option (`Xvfb :99 -ac -screen 0 1600x1200x24+32` according to the log). - Check your build environment and Qt5 packaging to make sure that it is not set up to require presence of some X11 extensions. Can you instantiate a simple top-level QWidget from that env? Is your Qt build with an QPA which maybe requires some X11 extension? By default, Xvfb doesn't even provide xrandr, but once again, Trojita doesn't really care. - Check your qtwebkit. Even if Qt5Gui works, the problem might be webkit-specific. If there's something that I can help with, please ask. However, since the Qt5 builds are passing in both our CI on CentOS, the KDE's traditional CI on ancient Ubuntu, and my Gentoo laptop, I'm pretty sure that there's no problem in Trojita.
Hi Jan, thanks for the explanation. > - Check xvfb-run's invocation. We're calling it with a bigger screen, different > bit depth and an -ac option (`Xvfb :99 -ac -screen 0 1600x1200x24+32` according > to the log). Yes but the strange thing about it all is that the test works when I build with qt4 instead of qt5. The html composition fails with qt5 only. An interesting point is also that the qt5 build needs both more space and takes a longer time for the complete run of cmake. Maybe we (Fedora) should first look if koji has an issue here with memory consumption.
> The html composition fails with qt5 only. No, but apparently QtWebkit from Qt5 makes unconditional usage of an X11 extension which (your version of?) xvfb doesn't provide, therefore the X11 server disconnects the client. For a simple test, try "xdpyinfo | grep -A50 extensions" on your xvfb (launch a server and "export DISPLAY=:99" to access it) @Jan, do the used xvfb versions inc. "traditional CI on ancient Ubuntu" provide the randr extension (it could *easily* be the problem if not provide by the problematic version, afair there were changes in 5.4 to hard-depend on it - and in 5.5 to soften that again ;-)
(In reply to Raphael Groner from comment #4) > Yes but the strange thing about it all is that the test works when I build > with qt4 instead of qt5. The html composition fails with qt5 only. That doesn't surprise me; Qt5 has a completely reworked graphics implementation. They are more like two separate libraries when viewed from this perspective. > An interesting point is also that the qt5 build needs both more space and takes > a longer time for the complete run of cmake. Are you sure you aren't accidentally using a debug version of Qt5? > Maybe we (Fedora) should first look if koji has an issue here with memory > consumption. The error message is not consistent with running low on memory, though. (In reply to Thomas Lübking from comment #5) > @Jan, do the used xvfb versions inc. "traditional CI on ancient Ubuntu" > provide the randr extension (it could *easily* be the problem if not provide > by the problematic version, afair there were changes in 5.4 to hard-depend > on it - and in 5.5 to soften that again ;-) Last time I checked, Xvfb required a not-yet-integrated patch for enabling xrandr. Here's what the CentOS5 CI reports: number of extensions: 22 BIG-REQUESTS Composite DAMAGE DOUBLE-BUFFER DPMS GLX Generic Event Extension MIT-SCREEN-SAVER MIT-SHM Present RECORD RENDER SGI-GLX SHAPE SYNC X-Resource XC-MISC XFIXES XInputExtension XKEYBOARD XTEST XVideo
Created attachment 91850 [details] build log from koji with failed test of html formatting a hopefully more detailled build log with the failed test of html formatting
I executed the html formatting testcase alone and it works! So I still guess an issue with running out of resources.
The relevant source snippet seems to be that: https://webcache.googleusercontent.com/search?q=cache:AY5C2IQNJYQJ:https://qt.gitorious.org/qt/qtbase/source/d52b00e1d3cc60c81b54a89d6da488dc4bbce384:src/plugins/platforms/xcb/qxcbconnection.cpp+&cd=4&hl=de&ct=clnk&gl=de (using google's webcache cause gitorious is not really usable)
> I executed the html formatting testcase alone and it works! On xvfb or your "real" X11 server?
(In reply to Thomas Lübking from comment #10) > > I executed the html formatting testcase alone and it works! > On xvfb or your "real" X11 server? xvfb (on official Fedora koji build system)
This starts to get interesting :(. Is that maybe a bug in libX11 where calling XQueryExtension triggers the global(?) error handler? Thomas, do you understand this? Shall we move this to the Qt's bugtracker? (gdb) bt #0 _XDefaultIOError (dpy=0x555555782b40) at /var/tmp/portage/x11-libs/libX11-1.6.2/work/libX11-1.6.2/src/XlibInt.c:1272 #1 0x00007fffeacb1a9d in ioErrorHandler (dpy=0x555555782b40) at /var/tmp/portage/dev-qt/qtgui-5.5.9999/work/qtgui-5.5.9999/src/plugins/platforms/xcb/qxcbconnection.cpp:116 #2 0x00007ffff1f29462 in _XIOError (dpy=dpy@entry=0x555555782b40) at /var/tmp/portage/x11-libs/libX11-1.6.2/work/libX11-1.6.2/src/XlibInt.c:1498 #3 0x00007ffff1f260ef in require_socket (dpy=0x555555782b40) at /var/tmp/portage/x11-libs/libX11-1.6.2/work/libX11-1.6.2/src/xcb_io.c:70 #4 0x00007ffff1f269ad in _XFlush (dpy=0x555555782b40) at /var/tmp/portage/x11-libs/libX11-1.6.2/work/libX11-1.6.2/src/xcb_io.c:511 #5 0x00007ffff1f29cc5 in _XGetRequest (dpy=dpy@entry=0x555555782b40, type=type@entry=98 'b', len=len@entry=8) at /var/tmp/portage/x11-libs/libX11-1.6.2/work/libX11-1.6.2/src/XlibInt.c:1735 #6 0x00007ffff1f1ae61 in XQueryExtension (dpy=0x555555782b40, name=0x7fffead03437 "XInputExtension", major_opcode=0x555555782768, first_event=0x55555578276c, first_error=0x555555782770) at /var/tmp/portage/x11-libs/libX11-1.6.2/work/libX11-1.6.2/src/QuExt.c:44 #7 0x00007fffeace0d7a in QXcbConnection::initializeXInput2 (this=this@entry=0x555555782750) at /var/tmp/portage/dev-qt/qtgui-5.5.9999/work/qtgui-5.5.9999/src/plugins/platforms/xcb/qxcbconnection_xi2.cpp:72 #8 0x00007fffeacb7bad in QXcbConnection::QXcbConnection (this=0x555555782750, nativeInterface=0x5555557826a0, canGrabServer=<optimized out>, displayName=0x0) at /var/tmp/portage/dev-qt/qtgui-5.5.9999/work/qtgui-5.5.9999/src/plugins/platforms/xcb/qxcbconnection.cpp:510 #9 0x00007fffeacbc23f in QXcbIntegration::QXcbIntegration (this=0x555555778fa0, parameters=..., argc=<optimized out>, argv=0x7fffffffd978) at /var/tmp/portage/dev-qt/qtgui-5.5.9999/work/qtgui-5.5.9999/src/plugins/platforms/xcb/qxcbintegration.cpp:170 #10 0x00007ffff7ff540e in QXcbIntegrationPlugin::create (this=<optimized out>, system=..., parameters=..., argc=@0x7fffffffd83c: 1, argv=0x7fffffffd978) at /var/tmp/portage/dev-qt/qtgui-5.5.9999/work/qtgui-5.5.9999/src/plugins/platforms/xcb/qxcbmain.cpp:50 #11 0x00007ffff47d9c3a in loadIntegration (argv=0x7fffffffd978, argc=@0x7fffffffd83c: 1, parameters=..., key=..., loader= 0x7ffff4c89c80 <_ZZN12_GLOBAL__N_112Q_QGS_loader13innerFunctionEvE6holder>) at /var/tmp/portage/dev-qt/qtgui-5.5.9999/work/qtgui-5.5.9999/src/gui/kernel/qplatformintegrationfactory.cpp:56 #12 QPlatformIntegrationFactory::create (platform=..., paramList=..., argc=@0x7fffffffd83c: 1, argv=argv@entry=0x7fffffffd978, platformPluginPath=...) at /var/tmp/portage/dev-qt/qtgui-5.5.9999/work/qtgui-5.5.9999/src/gui/kernel/qplatformintegrationfactory.cpp:73 #13 0x00007ffff47ea23c in init_platform (argv=0x7fffffffd978, argc=@0x7fffffffd83c: 1, platformThemeName=..., platformPluginPath=..., pluginArgument=...) at /var/tmp/portage/dev-qt/qtgui-5.5.9999/work/qtgui-5.5.9999/src/gui/kernel/qguiapplication.cpp:1019 #14 QGuiApplicationPrivate::createPlatformIntegration (this=0x5555557772b0) at /var/tmp/portage/dev-qt/qtgui-5.5.9999/work/qtgui-5.5.9999/src/gui/kernel/qguiapplication.cpp:1176 #15 0x00007ffff47eaec5 in QGuiApplicationPrivate::createEventDispatcher (this=<optimized out>) at /var/tmp/portage/dev-qt/qtgui-5.5.9999/work/qtgui-5.5.9999/src/gui/kernel/qguiapplication.cpp:1193 #16 0x00007ffff4499c58 in QCoreApplication::init (this=this@entry=0x7fffffffd840) at /var/tmp/portage/dev-qt/qtcore-5.5.9999/work/qtcore-5.5.9999/src/corelib/kernel/qcoreapplication.cpp:766 #17 0x00007ffff4499d09 in QCoreApplication::QCoreApplication (this=0x7fffffffd840, p=...) at /var/tmp/portage/dev-qt/qtcore-5.5.9999/work/qtcore-5.5.9999/src/corelib/kernel/qcoreapplication.cpp:688 #18 0x00007ffff47ed27f in QGuiApplication::QGuiApplication (this=0x7fffffffd840, p=...) at /var/tmp/portage/dev-qt/qtgui-5.5.9999/work/qtgui-5.5.9999/src/gui/kernel/qguiapplication.cpp:569 #19 0x00007ffff77e3d84 in QApplication::QApplication (this=0x7fffffffd840, argc=@0x7fffffffd83c: 1, argv=0x7fffffffd978, _internal=328960) at /var/tmp/portage/dev-qt/qtwidgets-5.5.9999/work/qtwidgets-5.5.9999/src/widgets/kernel/qapplication.cpp:569 #20 0x000055555555914b in main (argc=1, argv=0x7fffffffd978) at /home/jkt/work/prog/trojita/tests/Composer/test_Html_formatting.cpp:742
Anyway, https://bugreports.qt.io/browse/QTBUG-45388 .
The XIO error could just be a "client broke in other thread" error, the next X11 call will then cause this. -> If you can reproduce this at will, check the other thread stacks. Eg. anything dbus related could be considered fishy.
Not reproducible with Qt 4.5 unpatched but Qt 5.5 shows this bug. We guess any patch from Qt 5.5 is causing this bug.
Several duplicates have been reported so far. This is the most current one: https://bugreports.qt.io/browse/QTBUG-45624
This is an accidental breakage in Qt5, reported and with a patch under review. We do not have to track this explicitly in Trojita's bug tracker anymore. Thanks for your updates and pursuing this.