Bug 284633 - Konqueror with webkit burns the CPU on forum.softpedia.com
Summary: Konqueror with webkit burns the CPU on forum.softpedia.com
Status: RESOLVED UPSTREAM
Alias: None
Product: kwebkitpart
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: webkit-devel
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-10-21 18:15 UTC by András Manţia
Modified: 2011-11-23 08:31 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description András Manţia 2011-10-21 18:15:56 UTC
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:
Comment 1 Dawit Alemayehu 2011-10-21 18:39:36 UTC
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.
Comment 2 András Manţia 2011-10-22 15:46:15 UTC
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?
Comment 3 Dawit Alemayehu 2011-10-23 17:01:59 UTC
(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.
Comment 4 András Manţia 2011-10-24 15:16:03 UTC
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.
Comment 5 Dawit Alemayehu 2011-10-28 16:23:26 UTC
(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.
Comment 6 Dawit Alemayehu 2011-10-28 17:50:06 UTC
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
Comment 7 Dawit Alemayehu 2011-11-16 16:35:13 UTC
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
Comment 8 Dawit Alemayehu 2011-11-16 16:35:36 UTC
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
Comment 9 András Manţia 2011-11-23 08:08:15 UTC
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.
Comment 10 András Manţia 2011-11-23 08:31:54 UTC
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).