| Summary: | [qt overlay] dev-qt/qtgui-5.3.1 - click/hover events have no effect after random time | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Franz Trischberger <franz.trischberger> |
| Component: | [OLD] Library | Assignee: | Qt Bug Alias <qt> |
| Status: | RESOLVED NEEDINFO | ||
| Severity: | normal | CC: | franz.trischberger |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | emerge --info | ||
I just finished downloading Qt-5.3.1 official linux binaries. Ran qtcreator (contained as binary) for about 10-15 minutes. Not a single hang, where system qtcreator needs only <1 minute. So probably there is an issue in the way Gentoo packages Qt - or at least it uncovers an issue in my personal setup, as Devs seem to have no issue. Any hint where to look at? Are you sure this started happening since 5.3.0? There haven't been many packaging changes from 5.2.x to 5.3.0 AFAIR, so I wouldn't know where to start looking :/ I am not entirely sure. But I know that I gave qupzilla a try with every Qt5-update. It worked OK until I visited certain websites that make qtwebkit crash.
I moved away from KDE4 (trying Plasma5 now...) some time ago and mainly use tools not built on Qt (vim + llpp + firefox), though I regularly launched and used apps like qpdfview.
After the main qtwebkit crashing websites I often use got reworked (einestages.spiegel.de, kartor.eniro.se) I wanted to give qupzilla another chance as my main browser with Qt-5.3.0 - and immediately got those mouse issues described in this bugreport.
I know that I used qupzilla for a while around April 22 (because I had a discussion concerning qupzilla stability at that time ;)) and AFAIR everything was OK.
Tue Feb 25 14:24:35 2014 >>> dev-qt/qtwebkit-5.2.1
Sun May 25 17:24:20 2014 >>> dev-qt/qtwebkit-5.3.0
and that was with Qt-5.2.1.
When was the last major rework of qt5-build?
(In reply to Franz Fellner from comment #3) > When was the last major rework of qt5-build? The last major changes happened on 2014-07-21 (commit d81b3b0001165085978c2e4a79f754fd871037ed) and in the next few days. Between April 22 and May 25 the only potentially relevant commit that I could find is a0c7e1c1c4e784b73c1c7a4fcc5824dbfb0beca5, although nothing should have really changed unless you use egl and/or evdev... Sry for the late response. I played around with USE-Flags. disabled everything egl/evdev related. No success. Enabled everything egl related - no success. evdev did not change anything either. I really hope this will magically be fixed with the next Qt5 update :( But I don't think that will happen... As nobody else seems to have those issues it must be an issue with my setup. Weird... Just tested with a new user and I didn't have a single lockup in 20 minutes power-click/drag/...-usage. So somewhere in my settings I have a config lying around that makes Qt5 installed by portage lockup but not the one pre-compiled by qt-project.org. MEH! This will take quite a while, and I don't know when I will have the time :( (Already tried moving away Trolltech* and QtProject*, which did not help. With KDE5 configs get scattered in ~/.config/ so no easy way to clean kde settings anymore...) Do you have anything in /etc/qt5/ ? (In reply to Davide Pesavento from comment #7) > Do you have anything in /etc/qt5/ ? No. I even don't have /etc/qt5 ;) Ok, I'm going to close as NEEDINFO since we don't know what is causing this behavior and we haven't been able to reproduce it. I believe it's likely to be a weird configuration issue, but please do reopen if you find out that it's an actual packaging (or upstream) bug. Thanks. NEEDSINFO is fine. Hope it's OK to post further findings/tries her. The testuser now also suffers from the same issue, even with empty $HOME, so this was a single lucky shot... Some sort of race during initialization/lib loading? In the meantime I recompiled Qt-deps of qpdfview without distcc - no luck. I set empty C[XX]FLAGS for Qt packages so Qt build system can chose whatever is best - no luck. $ diff -u <(ldd /usr/lib64/libQt5Gui.so.5.3.1) <(ldd /home/franz/Qt5.3.1/5.3/gcc_64/lib/libQt5Gui.so.5.3.1) --- /proc/self/fd/11 2014-08-27 11:50:37.941699430 +0200 +++ /proc/self/fd/12 2014-08-27 11:50:37.942699482 +0200 @@ -1,19 +1,29 @@ - linux-vdso.so.1 (0x00007ffff6bff000) - libQt5Core.so.5 => /home/franz/Qt5.3.1/5.3/gcc_64/lib/libQt5Core.so.5 (0x00007fa5935b4000) - libpng16.so.16 => /usr/lib64/libpng16.so.16 (0x00007fa593353000) - libz.so.1 => /lib64/libz.so.1 (0x00007fa59313d000) - libGLESv2.so.2 => /usr/lib64/libGLESv2.so.2 (0x00007fa592f36000) - libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libstdc++.so.6 (0x00007fa592c30000) - libm.so.6 => /lib64/libm.so.6 (0x00007fa592938000) - libc.so.6 => /lib64/libc.so.6 (0x00007fa592595000) - libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fa592377000) - libicui18n.so.52 => /home/franz/Qt5.3.1/5.3/gcc_64/lib/libicui18n.so.52 (0x00007fa591f57000) - libicuuc.so.52 => /home/franz/Qt5.3.1/5.3/gcc_64/lib/libicuuc.so.52 (0x00007fa591bcf000) - libdl.so.2 => /lib64/libdl.so.2 (0x00007fa5919ca000) - libgthread-2.0.so.0 => /usr/lib64/libgthread-2.0.so.0 (0x00007fa5917c8000) - librt.so.1 => /lib64/librt.so.1 (0x00007fa5915c0000) - libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0 (0x00007fa59128c000) - libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libgcc_s.so.1 (0x00007fa591076000) - /lib64/ld-linux-x86-64.so.2 (0x00007fa5943a9000) - libglapi.so.0 => /usr/lib64/libglapi.so.0 (0x00007fa590e4d000) - libicudata.so.52 => /home/franz/Qt5.3.1/5.3/gcc_64/lib/libicudata.so.52 (0x00007fa58f5e1000) + linux-vdso.so.1 (0x00007fffc68e6000) + libQt5Core.so.5 => /home/franz/Qt5.3.1/5.3/gcc_64/lib/libQt5Core.so.5 (0x00007fb279300000) + libGL.so.1 => /usr/lib64/libGL.so.1 (0x00007fb279071000) + libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libstdc++.so.6 (0x00007fb278d6c000) + libm.so.6 => /lib64/libm.so.6 (0x00007fb278a74000) + libc.so.6 => /lib64/libc.so.6 (0x00007fb2786d0000) + libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fb2784b3000) + libicui18n.so.52 => /home/franz/Qt5.3.1/5.3/gcc_64/lib/libicui18n.so.52 (0x00007fb278093000) + libicuuc.so.52 => /home/franz/Qt5.3.1/5.3/gcc_64/lib/libicuuc.so.52 (0x00007fb277d0a000) + libdl.so.2 => /lib64/libdl.so.2 (0x00007fb277b06000) + libgthread-2.0.so.0 => /usr/lib64/libgthread-2.0.so.0 (0x00007fb277904000) + librt.so.1 => /lib64/librt.so.1 (0x00007fb2776fb000) + libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0 (0x00007fb2773c8000) + libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libgcc_s.so.1 (0x00007fb2771b2000) + /lib64/ld-linux-x86-64.so.2 (0x00007fb27a158000) + libglapi.so.0 => /usr/lib64/libglapi.so.0 (0x00007fb276f88000) + libXext.so.6 => /usr/lib64/libXext.so.6 (0x00007fb276d76000) + libXdamage.so.1 => /usr/lib64/libXdamage.so.1 (0x00007fb276b73000) + libXfixes.so.3 => /usr/lib64/libXfixes.so.3 (0x00007fb27696c000) + libX11-xcb.so.1 => /usr/lib64/libX11-xcb.so.1 (0x00007fb27676a000) + libX11.so.6 => /usr/lib64/libX11.so.6 (0x00007fb276430000) + libxcb-glx.so.0 => /usr/lib64/libxcb-glx.so.0 (0x00007fb276217000) + libxcb-dri2.so.0 => /usr/lib64/libxcb-dri2.so.0 (0x00007fb276012000) + libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007fb275df2000) + libXxf86vm.so.1 => /usr/lib64/libXxf86vm.so.1 (0x00007fb275beb000) + libdrm.so.2 => /usr/lib64/libdrm.so.2 (0x00007fb2759df000) + libicudata.so.52 => /home/franz/Qt5.3.1/5.3/gcc_64/lib/libicudata.so.52 (0x00007fb274173000) + libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007fb273f6f000) + libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x00007fb273d68000) So I added -lX11 -lxcb -lX11-xcb (as a first shot) to LDFLAGS. But on install they seem to get removed, although they appear in the link command. Weird. Is there a switch in the configure script that strips unneeded libraries? Portage feature? Or is X/xcb disabled in Gentoo for libQt5Gui, enabled only for the platform plugin? (sry just fishing in the dark...) I now HACKed my env and use LD_LIBRARY_PATH + QT_PLUGIN_PATH to prefer Qt5 libs/plugins installed in my home. Works really well for now, but I have a bad feeling ;) (In reply to Franz Fellner from comment #10) > NEEDSINFO is fine. Hope it's OK to post further findings/tries her. Absolutely, yes. > So I added -lX11 -lxcb -lX11-xcb (as a first shot) to LDFLAGS. But on > install they seem to get removed, although they appear in the link command. > Weird. > Is there a switch in the configure script that strips unneeded libraries? > Portage feature? Or is X/xcb disabled in Gentoo for libQt5Gui, enabled only > for the platform plugin? > (sry just fishing in the dark...) -Wl,--as-needed probably (it's part of the default portage LDFLAGS). In any case, X11 libraries are only used by the xcb platform plugin, not by libQt5Gui.so itself. (In reply to Franz Fellner from comment #10) > $ diff -u <(ldd /usr/lib64/libQt5Gui.so.5.3.1) <(ldd > /home/franz/Qt5.3.1/5.3/gcc_64/lib/libQt5Gui.so.5.3.1) > --- /proc/self/fd/11 2014-08-27 11:50:37.941699430 +0200 > +++ /proc/self/fd/12 2014-08-27 11:50:37.942699482 +0200 > @@ -1,19 +1,29 @@ > - linux-vdso.so.1 (0x00007ffff6bff000) > - libQt5Core.so.5 => > /home/franz/Qt5.3.1/5.3/gcc_64/lib/libQt5Core.so.5 (0x00007fa5935b4000) This doesn't look good at all. System qtgui should link to system qtcore, i.e. /usr/lib64/libQt5Core.so.5.3.1 (In reply to Davide Pesavento from comment #12) > (In reply to Franz Fellner from comment #10) > > $ diff -u <(ldd /usr/lib64/libQt5Gui.so.5.3.1) <(ldd > > /home/franz/Qt5.3.1/5.3/gcc_64/lib/libQt5Gui.so.5.3.1) > > --- /proc/self/fd/11 2014-08-27 11:50:37.941699430 +0200 > > +++ /proc/self/fd/12 2014-08-27 11:50:37.942699482 +0200 > > @@ -1,19 +1,29 @@ > > - linux-vdso.so.1 (0x00007ffff6bff000) > > - libQt5Core.so.5 => > > /home/franz/Qt5.3.1/5.3/gcc_64/lib/libQt5Core.so.5 (0x00007fa5935b4000) > > This doesn't look good at all. System qtgui should link to system qtcore, > i.e. /usr/lib64/libQt5Core.so.5.3.1 ARGH, sry, my mistake. As I said I made Qt5-apps work by setting LD_LIBRARY_PATH. I simply copied the diff from the wrong term window. Without LD_LIBRARY_PATH set of course system libQt5Core is used and ldd shows the correct path. It looks as if this issue solved itself after upgrading to 5.4 alpha. I will leave it open in case problems reappear. |
Created attachment 381654 [details] emerge --info I have this issue since about Qt 5.3.0 (AFAIR), 5.2.x was OK: The application simply does not react on mouse clicks or hover events. E.g. List views don't change their state when the mouse enters the widget. Menus don't open on click, buttons don't react on click. But it's not a complete freeze: I can scroll, e.g. web pages in qupzilla or the tree view representing the TOC in qpdfview. Also the keyboard works fine, I can tab through the widgets and fill Line/Text edits and navigate to buttons and hit enter to trigger their attached actions. Though this is really uncomfortable, especially in bigger apps... I could not find anything related in Xorg.0.log or .xsession-errors (though that does not mean anything ;)) I do not have any issue with apps using GTK (:2 and :3) or EFL. The issue sometimes appears directly after start, sometimes I can use it for a (very) short time. If the app freezes I can make it accept mouse events again (sometimes, at least - for a short time) by changing to another window and press some keys/interact/... As KF5 forced gcc-4.8 on me I already did an emerge -e world - with no success. I disabled USE=glib for qt{core,gui}, as the backtrace showed a hang in QGlibEventDispatcher (poll) - which resulted in hanging in QEventDispatcherUNIX ;) I even updated to xorg-server-1.16.0 and xf86-input-evdev-2.9.0 (using only evdev) with no result. ======== ========= $ emerge -pv --nodeps qtcore qtgui xf86-input-evdev xorg-server xorg-drivers These are the packages that would be merged, in order: [ebuild R ~] dev-qt/qtcore-5.3.1:5::qt USE="glib icu -debug {-test}" 0 kB [ebuild R ~] dev-qt/qtgui-5.3.1:5::qt USE="egl evdev gif glib harfbuzz jpeg opengl png udev xcb -accessibility -debug -eglfs -gles2 -ibus -kms {-test}" 0 kB [ebuild R #] x11-drivers/xf86-input-evdev-2.9.0 0 kB [ebuild R ~] x11-base/xorg-server-1.16.0:0/1.16.0 USE="ipv6 nptl suid systemd udev wayland xorg -dmx -doc (-glamor) -kdrive -minimal (-selinux) -static-libs -tslib -unwind -xnest -xvfb" 0 kB [ebuild R ~] x11-base/xorg-drivers-1.16 INPUT_DEVICES="evdev wacom -acecad -aiptek -elographics -fpit -hyperpen -joystick -keyboard -mouse -mutouch -penmount -synaptics -tslib -vmmouse -void" VIDEO_CARDS="intel -apm -ast -chips -cirrus -dummy -epson -fbdev -fglrx (-freedreno) (-geode) -glint -i128 (-i740) -mach64 -mga -modesetting -neomagic -nouveau -nv -nvidia (-omap) (-omapfb) -qxl -r128 -radeon -radeonsi -rendition -s3 -s3virge -savage -siliconmotion -sisusb (-sunbw2) (-suncg14) (-suncg3) (-suncg6) (-sunffb) (-sunleo) (-suntcx) -tdfx -tga -trident -tseng -v4l -vesa -via -virtualbox -vmware (-voodoo)" 0 kB