Version: unspecified (using Devel) OS: Linux Virtually on any forum page from http://forum.softpedia.com/ makes Konqueror and XOrg . Just load one, eg. http://forum.softpedia.com/index.php?showtopic=808906&st=0&start=0 , wait a little and see it.Konqueror is at 95% CPU, Xorg 82% CPU. openSUSE 11.4, self compile KDE, Qt 4.7.4 (actually the 4.7 branch from git). Reproducible: Always Actual Results: Expected Results:
This would be an upstream QtWebKit issue. However, I can tell you that I cannot duplicate the issue with QtWebKit 2.2 ; the version of QtWebKit that will come with Qt 4.8.
I can reproduce with Qt 4.8 branch as well. :( I can report upstream, but with the webkit versioning and hosting madness (qtwebkit-2, qtwebkit, different webkit versions), I wasn't sure on which bugzilla or which product/version should I report. Webkit Qt? And what version (I see lots of versions like 412.x or such)? Can you guide me on this?
(In reply to comment #2) > I can reproduce with Qt 4.8 branch as well. :( I can report upstream, but with > the webkit versioning and hosting madness (qtwebkit-2, qtwebkit, different > webkit versions), I wasn't sure on which bugzilla or which product/version > should I report. Hmm... I cannot reproduce the problem with QtWebKit 2.2 which is based on the old (read: non process based) webkit1. However, I do see the spike in CPU usage on some other sites. For example, if I go to news.google.com and scroll the page ; so something weird is happening probably with the JS engine. > Webkit Qt? And what version (I see lots of versions like 412.x or such)? > Can you guide me on this? Sure. Use the bug reporting instruction and template they provide at http://trac.webkit.org/wiki/QtWebKitBugs and for version, simply pick the latest one. That is what I always do. Also Make sure after you open the ticket, add the word "Qt" to the Keywords entry.
Before opening a report for webkit, can you check that you don't have any ad blocker running? With an ad blocker, I don't see the problem.
(In reply to comment #4) > Before opening a report for webkit, can you check that you don't have any ad > blocker running? With an ad blocker, I don't see the problem. I do not use the ad blocker. Actually, I used an external ad proxy server (privoxy), but that does not seem to matter. Anyhow, I do not see the issue you are seeing at those forums, but I suspect what might be causing the issue. Can you please try to generate a backtrace when konqueror starts eating the CPU ? You can do that by attaching gdb to the running instance, e.g. gdb kdeinit4 <pid> or gdb konqueror <pid>. I found out that the CPU spikes on my system were caused by the javascript code kdewebkit executes to find forms on a webpage for automatic form filling. Not entirely sure why that only happens intermittently at this point, but I suspect it is related to the finished signal being emitted prematurely QWebPage. Perhaps your problem is also caused by this as well.
Git commit b54533f77645b9fbeb8b3073db9c0763e1a9ed1f by Dawit Alemayehu. Committed on 28/10/2011 at 18:56. Pushed by adawit into branch 'KDE/4.7'. Check for the number of forms and number of elements in the forms only once. This avoids a nasty bug where we start checking for forms on a webpage that has not yet finished loading. CCBUG: 284633 FIXED: 4.7.4 M +4 -2 kdewebkit/kwebwallet.cpp http://commits.kde.org/kdelibs/b54533f77645b9fbeb8b3073db9c0763e1a9ed1f
Git commit b9d9fa895ddd8ea43acf5a64de6e28d6997650b2 by Dawit Alemayehu. Committed on 16/11/2011 at 17:23. Pushed by adawit into branch '1.2'. Workaround QtWebKit's propensity to emit the loadFinished signal multiple times causing kwebkitpart to unnecessarily perform rather CPU intensive actions like filling forms on a page over and over again. BUG: 284633 M +6 -0 src/kwebkitpart.cpp M +1 -0 src/kwebkitpart.h http://commits.kde.org/kwebkitpart/b9d9fa895ddd8ea43acf5a64de6e28d6997650b2
Git commit 1846357a704ac74b09fff18f7f0ea267680a631e by Dawit Alemayehu. Committed on 16/11/2011 at 17:23. Pushed by adawit into branch 'master'. Workaround QtWebKit's propensity to emit the loadFinished signal multiple times causing kwebkitpart to unnecessarily perform rather CPU intensive actions like filling forms on a page over and over again. BUG: 284633 M +6 -0 src/kwebkitpart.cpp M +1 -0 src/kwebkitpart.h http://commits.kde.org/kwebkitpart/1846357a704ac74b09fff18f7f0ea267680a631e
The bug is not fixed though, but probably it is ouside of kwebkitpart. The backtrace doesn't show too much if run through gdb: 3 (gdb) c Continuing. ^C Program received signal SIGINT, Interrupt. 0x00007ffff4439dcd in read () from /lib64/libpthread.so.0 (gdb) bt #0 0x00007ffff4439dcd in read () from /lib64/libpthread.so.0 #1 0x00007fffed1176ad in ?? () from /usr/lib64/libxcb.so.1 #2 0x00007fffed115cf2 in ?? () from /usr/lib64/libxcb.so.1 #3 0x00007fffed11723f in xcb_wait_for_reply () from /usr/lib64/libxcb.so.1 #4 0x00007ffff2a1d0bd in _XReply () from /usr/lib64/libX11.so.6 #5 0x00007ffff2a002f0 in XGetGeometry () from /usr/lib64/libX11.so.6 #6 0x00007fff9795b591 in ?? () from /usr/lib64/libgdk-x11-2.0.so.0 #7 0x00007fff979312a4 in gdk_window_get_geometry () from /usr/lib64/libgdk-x11-2.0.so.0 #8 0x00007fff97929b40 in gdk_screen_get_monitor_at_window () from /usr/lib64/libgdk-x11-2.0.so.0 #9 0x00007fffdf4ac948 in ?? () from /usr/lib64/browser-plugins/libflashplayer.so #10 0x00007fffdf4c4373 in ?? () from /usr/lib64/browser-plugins/libflashplayer.so #11 0x00007fffdf4aeb22 in ?? () from /usr/lib64/browser-plugins/libflashplayer.so #12 0x00007fffdf4aef74 in ?? () from /usr/lib64/browser-plugins/libflashplayer.so #13 0x00007fff97ce1958 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 #14 0x00007fffed773a14 in g_closure_invoke () from /usr/lib64/libgobject-2.0.so.0 #15 0x00007fffed78599a in ?? () from /usr/lib64/libgobject-2.0.so.0 #16 0x00007fffed78edf3 in g_signal_emit_valist () from /usr/lib64/libgobject-2.0.so.0 #17 0x00007fffed78f1c2 in g_signal_emit () from /usr/lib64/libgobject-2.0.so.0 #18 0x00007fff97dfa7c0 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 #19 0x00007fff97ce0137 in gtk_main_do_event () from /usr/lib64/libgtk-x11-2.0.so.0 #20 0x00007fff97932cc4 in ?? () from /usr/lib64/libgdk-x11-2.0.so.0 #21 0x00007fff9792dc63 in ?? () from /usr/lib64/libgdk-x11-2.0.so.0 #22 0x00007fff9792fe01 in gdk_window_process_all_updates () from /usr/lib64/libgdk-x11-2.0.so.0 #23 0x00007fff97c63281 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 #24 0x00007fff9790d346 in ?? () from /usr/lib64/libgdk-x11-2.0.so.0 #25 0x00007fffedeb158d in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0 #26 0x00007fffedeb1d88 in ?? () from /usr/lib64/libglib-2.0.so.0 #27 0x00007fffedeb1f59 in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0 #28 0x00007ffff4860d85 in QEventDispatcherGlib::processEvents (this=0x60d640, flags=...) at kernel/qeventdispatcher_glib.cpp:424 #29 0x00007ffff348f46e in QGuiEventDispatcherGlib::processEvents (this=0x60d640, flags=...) at kernel/qguieventdispatcher_glib.cpp:204 #30 0x00007ffff4821a2a in QEventLoop::processEvents (this=0x7fffffffd0a0, flags=...) at kernel/qeventloop.cpp:149 #31 0x00007ffff4821bb4 in QEventLoop::exec (this=0x7fffffffd0a0, flags=...) at kernel/qeventloop.cpp:204 #32 0x00007ffff4824846 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1148 #33 0x00007ffff33b3252 in QApplication::exec () at kernel/qapplication.cpp:3811 #34 0x00007ffff7bab5b2 in kdemain (argc=<optimized out>, argv=<optimized out>) at /encrypted/home/andris/development/sources/kde-trunk/kde-baseapps/konqueror/src/konqmain.cpp:227 What I found: - it doesn't happen with an adblocker - it doesn't happen with privoxy (that also filters out flash ads) - it doesn't happen with export QT_NO_GLIB=1 So it is probably related to flash integration into webkit. I will report upstream as well.
Reported as https://bugs.webkit.org/show_bug.cgi?id=73006 and now I confirmed it is not a kwebkitpart issue (reproducible with fancybrowser from Qt).