QtWebkit based browsers freeze/crash

Question

Hello everybody! I'm using arch x86_64 on my laptop for quite some while now.
I have a strange issue with qtwebkit based browsers (QupZilla,Konqueror,Rekonq), just as I try to open an URL or search something Konqueror and Rekonq freeze. They are completely stuck and nothing responds, if I wait long enough (sometimes 1min+) it finally loads the page but it's unusable.
Qupzilla keeps being responsive but does not display any content, clicking on the page makes the application crash.
The crashlog:
Time: Wed Jan 16 19:00:38 2013
Qt version: 4.8.4 (compiled with 4.8.3)
QupZilla version: 1.3.5
WebKit version: 537.21
============== BACKTRACE ==============
#0: qupzilla() [0x402bac]
#1: /usr/lib/libc.so.6(+0x35340) [0x7fcbc109f340]
#2: /usr/lib/libQtWebKit.so.4(+0xc997a9) [0x7fcbc37437a9]
#3: /usr/lib/libQtWebKit.so.4(+0x4017f8) [0x7fcbc2eab7f8]
#4: /usr/lib/libQtWebKit.so.4(_ZNK9QWebFrame14hitTestContentERK6QPoint+0x132) [0x7fcbc2eabe12]
#5: /usr/lib/libQtWebKit.so.4(_ZNK8QWebPage7frameAtERK6QPoint+0x50) [0x7fcbc2ebe8d0]
#6: /usr/lib/libQupZilla.so.1(_ZN7WebView15mousePressEventEP11QMouseEvent+0x157) [0x7fcbc4fd2b67]
#7: /usr/lib/libQtGui.so.4(_ZN7QWidget5eventEP6QEvent+0x910) [0x7fcbc2020a30]
#8: /usr/lib/libQtWebKit.so.4(_ZN8QWebView5eventEP6QEvent+0x77) [0x7fcbc2ec58d7]
#9: /usr/lib/libQtGui.so.4(_ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent+0xac) [0x7fcbc1fd118c]
#10: /usr/lib/libQtGui.so.4(_ZN12QApplication6notifyEP7QObjectP6QEvent+0x99b) [0x7fcbc1fd5e6b]
#11: /usr/lib/libQtCore.so.4(_ZN16QCoreApplication14notifyInternalEP7QObjectP6QEvent+0x8e) [0x7fcbc1aa76ae]
#12: /usr/lib/libQtGui.so.4(_ZN19QApplicationPrivate14sendMouseEventEP7QWidgetP11QMouseEventS1_S1_PS1_R8QPointerIS0_Eb+0x14b) [0x7fcbc1fd1fcb]
#13: /usr/lib/libQtGui.so.4(+0x245ad4) [0x7fcbc204cad4]
#14: /usr/lib/libQtGui.so.4(_ZN12QApplication15x11ProcessEventEP7_XEvent+0xb11) [0x7fcbc204b861]
#15: /usr/lib/libQtGui.so.4(+0x26aa22) [0x7fcbc2071a22]
#16: /usr/lib/libglib-2.0.so.0(g_main_context_dispatch+0x135) [0x7fcbbe470845]
#17: /usr/lib/libglib-2.0.so.0(+0x47b78) [0x7fcbbe470b78]
#18: /usr/lib/libglib-2.0.so.0(g_main_context_iteration+0x34) [0x7fcbbe470c34]
#19: /usr/lib/libQtCore.so.4(_ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE+0x66) [0x7fcbc1ad5b66]
#20: /usr/lib/libQtGui.so.4(+0x26a69e) [0x7fcbc207169e]
#21: /usr/lib/libQtCore.so.4(_ZN10QEventLoop13processEventsE6QFlagsINS_17ProcessEventsFlagEE+0x2f) [0x7fcbc1aa63ff]
#22: /usr/lib/libQtCore.so.4(_ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE+0x138) [0x7fcbc1aa6688]
#23: /usr/lib/libQtCore.so.4(_ZN16QCoreApplication4execEv+0x88) [0x7fcbc1aab328]
#24: qupzilla() [0x402697]
#25: /usr/lib/libc.so.6(__libc_start_main+0xf5) [0x7fcbc108ba15]
#26: qupzilla() [0x402971]
Package versions:
extra/qtwebkit 2.3git20130115-1
community/qupzilla 1.3.5-3
extra/kdebase-konqueror 4.9.5-1
community/rekonq 2.0-2
No issues with Chromium,Firefox,Opera,Midori. There's some problem with the QtWebkit library it seems. Any ideas on how to fix this?

Answer 1

seth wrote:
Apparently there was an update from 2.2 to 2.3git, but at least qupzilla wasn't even rebuilt.
Use ARM to downgrade qtwebkit until the resp. maintainers notice this apparent ABI break and provide rebuilds of the using packages
http://arm.konnichi.com/search/index.ph … ommunity=1
pacman -U http://arm.konnichi.com/extra/os/x86_64 … pkg.tar.xz
Hi seth! Thank you for replying.
I investigated the issue a bit further. I'm using a zen kernel with custom config. And since I've seen no one else having trouble with the concerned applications, I thought it might also be possible there's something I enabled in the kernel that these programs didn't like instead of it being a qtwebkit problem.
Indeed, booting up the stock arch kernel I seemingly couldn't reproduce the issue. In zen when starting and using these applications I saw the worker "uksmd" go up and down in the process list (I had Ultra KSM enabled in my kernel configs for quite some while), after seeing a few comments about how it could use up quite a bit of processor time I disabled it and recompiled the kernel. After boot Konqueror, Rekonq were usable and didn't freeze. Qupzilla was only usable after downgrading qtwebkit as you told me.
The thing is, after a while Konqueror and Rekonq became stuck/frozen again (starting them again after a couple of minutes, though I was running Chromium in between to do some more research so it may have something to do with that...) surprisingly QupZilla is not having these issues.
I have my doubts that uksm is really responsible. I need to do some longer and more extensive tests with the arch kernel.
EDIT: Alright, I can say with certainty now that the same happens with the stock arch kernel. The issue manifests itself after a couple of minutes after booting up the system, Konqueror and Rekonq become unusable and freeze. They behave normally, without freezing, if you launch them a short time after the system is ready to use.
As I see it, Uksm is not the cause of this problem.
EDIT2: I think I found the real cause. In KDE's Network Settings I enabled "Detect proxy configuration automatically" because at my University we need to go through a proxy server to access the internet. Chromium uses these settings automatically and it works as intended. But having this enabled makes Rekonq or Konqueror crawl.
Last edited by popsUlfr (2013-01-18 19:56:05)