| Summary: | drains CPU after visiting pages with Flash | ||
|---|---|---|---|
| Product: | [Applications] konqueror | Reporter: | Marcus Better <marcus> |
| Component: | nspluginviewer | Assignee: | Konqueror Developers <konq-bugs> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | normal | CC: | alexandre.sidorenko, amantia, daniel.dumitrache, dimsuz, dominik.stadler, fabio.varesano, frederic.coiffier, hans.ullrich, honda, hubn3rd, Icekiss, jjm, jk, kde, kde, kfunk, kmg952, ks, le.petit.fou, magnus.kessler, mail, mrgrim, mrmazda, mutlu_inek, oliver.henshaw, p.malishev, rasasi78, roejames12, s.hs, Simon80, smaudet, stavallo, stefan.fleckenstein, vdboor, wrar, yg |
| Priority: | NOR | ||
| Version: | 4.2.0 | ||
| Target Milestone: | --- | ||
| Platform: | Debian testing | ||
| OS: | Unspecified | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
(Running Debian amd64 testing.) Related bug reports: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=513921 http://bugs.gentoo.org/229219 https://bugs.launchpad.net/ubuntu/+source/flashplugin-nonfree/+bug/240930/ I am also experiencing this on Fedora 10. If this cannot be fixed, can nspluginviewer be disabled as this issue is a real PITA. I experience the same issue with KDE 4.2.1 on 64-bit Gentoo and the 64-bit Adobe flash plugin. *** This bug has been confirmed by popular vote. *** I can confirm this for debian unstable running kde 4.2.2. It is especially annoying since multiple nspluginviewer processes get spawned over time, meaning that even the cpus in my dual core system are maxed out pretty fast just doing whatever for flash animations on tabs which are closed by now... (In reply to comment #6) > I can confirm this for debian unstable running kde 4.2.2. Me too. This seems due to many timer events asserted in 3 different widgets in nspluginviwer. If you comment out timer event routines in both glibevents.cpp and xtevents.cpp, then the problem has gone in my case. Without these timer events, flashplayer seems to be work fine. Anyway this is a hint for us to solve the problem. i can confirm this for kde 4.2.90 on kubuntu 9.04. I investigated this problem much further, and I think now that this is related to Qt's glib support (in paricular, polling of events). This bug and Bug 154270 (heavy Xorg and KWin cpu usage with Desktop Effects) perhaps comes from the same reason. So, try to set an enviorment variable: export QT_NO_GLIB=1 before your kde session start. Happens to me too, amd64 architecture, kde 4.2.4, akregator 1.4.4. I didn't get a chance to try the suggestion from comment #9 yet. (In reply to comment #9) > I investigated this problem much further, and I think now that this is related > to Qt's glib support (in paricular, polling of events). > This bug and Bug 154270 (heavy Xorg and KWin cpu usage with Desktop Effects) > perhaps comes from the same reason. > So, try to set an enviorment variable: > export QT_NO_GLIB=1 > before your kde session start. I just tried this, I set it before running akregator from a konsole and the problem seems to be gone! Afterward, I unset and ran akregator again and the excessive CPU usage returned. So I think you are on the right path. Thanks. *** Bug 198470 has been marked as a duplicate of this bug. *** Is https://bugzilla.redhat.com/show_bug.cgi?id=426968 related? I'm not sure whether nspluginviewer and nspluginwrapper have similar roots. I have put this "export QT_NO_GLIB=1" now before calling every browser, and it finally gives me internet back :-) I had a lot of trouble with the speed of the browsers. With this setting everything works just fine and fast as it should. I accelerates the browsers on both KDE 3.5 and 4.3 Hello I use the following to install flash - using 11.2 milestone7 live kde cd Install [Adobe Flash Player] http://get.adobe.com/flashplayer/ version 10.0.32.18 on x86_64 systems extract and copy plugin and it displays with about:plugins # cp -v libflashplayer.so /usr/lib64/browser-plugins/. about:plugins shows Shockwave Flash File name: libflashplayer.so Shockwave Flash 10.0 r32 I tested it with this http://sendables.jibjab.com/originals/2008_year_in_review Enjoy. I am experiencing this on Arch Linux as well, using KDE 4.3.2. When I use akregator for a while, the nspluginviewer process starts to take up between 10% and 20% cpu. The process is not stopped when I navigate away from feed content with flash to feeds in simple text view. Nspluginviewer quits only if I kill it manually or if I quit akregator. As mentioned above, starting akregator with "QT_NO_GLIB=1 akregator" solves the problem. I've created ~/.kde/env/nsplugin_fix.sh with "export QT_NO_GLIB=1" and now nspluginviewer stays after closed tab but it does not take all my cpu. KDE 4.3.2 from Kubuntu Karmic. The problem was there even in kde3. I can confirm that following #17 fixes this. Actually I used ~/.kde4/env/nsplugin_fix.sh as file path (kde4 instead of kde). This happens with trunk as well. I use the 64bit flash plugin, without npwrapper. Without QT_NO_GLIB=1, nspluginviewer uses 20% CPU according to top (from 4 CPU, AFAIK that means almost 100% for one CPU). It works OK while the page is visible, but as soon as I close it, the cpu usage goes up. If I attach gdb to it, I get nothing but:
#0 0x00007f5e0f1cc033 in poll () from /lib64/libc.so.6
#1 0x00007f5e12d3e58c in ?? () from /usr/lib64/libglib-2.0.so.0
#2 0x00007f5e12d3e8d0 in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#3 0x00007f5e1101c99f in QEventDispatcherGlib::processEvents (this=0x635230, flags=...)
at /home/andris/development/sources/kde-trunk/qt-copy/src/corelib/kernel/qeventdispatcher_glib.cpp:407
#4 0x00007f5e0fee96a4 in QGuiEventDispatcherGlib::processEvents (this=0x635230, flags=...)
at /home/andris/development/sources/kde-trunk/qt-copy/src/gui/kernel/qguieventdispatcher_glib.cpp:202
#5 0x00007f5e10fdcc14 in QEventLoop::processEvents (this=0x7fffd73e1300, flags=...) at /home/andris/development/sources/kde-trunk/qt-copy/src/corelib/kernel/qeventloop.cpp:149
#6 0x00007f5e10fdcd6a in QEventLoop::exec (this=0x7fffd73e1300, flags=...) at /home/andris/development/sources/kde-trunk/qt-copy/src/corelib/kernel/qeventloop.cpp:201
#7 0x00007f5e10fe02f2 in QCoreApplication::exec () at /home/andris/development/sources/kde-trunk/qt-copy/src/corelib/kernel/qcoreapplication.cpp:981
#8 0x00007f5e0fe00414 in QApplication::exec () at /home/andris/development/sources/kde-trunk/qt-copy/src/gui/kernel/qapplication.cpp:3572
#9 0x000000000041a03d in main (argc=3, argv=0x7fffd73e17a8) at /home/andris/development/sources/kde-trunk/kdebase/apps/nsplugins/viewer/viewer.cpp:144
Running Qt 4.6 (from git),KDE trunk, libflashplayer-10.0.32.18.linux-x86_64.so.tar.gz .
Yeah, something that bugs me regularly in trunk :) Adding myself to CC *** Bug 149022 has been marked as a duplicate of this bug. *** *** Bug 210148 has been marked as a duplicate of this bug. *** *** Bug 206604 has been marked as a duplicate of this bug. *** SVN commit 1075295 by orlovich: Try to avoid needless wakeups with the event pumps when not needed: - Don't activate the Xt pump when not needed; it's not for most commonly used plugins - Don't use our glib pump's timer when Qt's glib event loop is on anyway. This doesn't cover 100% of situations, and doesn't really explain why QT_NO_GLIB works better for some people (never saw this particular case myself), but it should cover the "nspluginviewer wakes up a lot and uses a few% of cpu" case for most people. Hopefully. CCBUG: 182869 I am thinking off holding of on backporting this till 4.4.1, though.... M +22 -5 glibevents.cpp M +6 -5 glibevents.h M +3 -0 pluginhost_xt.cpp M +16 -7 xtevents.cpp M +7 -5 xtevents.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1075295 Can this patch be included in SC 4.4 final? This bug makes konqueror unuseable for me, it's a pity.
>
> WebSVN link: http://websvn.kde.org/?view=rev&revision=1075295
>
> I am thinking off holding of on backporting this till 4.4.1, though....
>
After some more investigation, I'm not quite sure anymore, if my problem is really related to this report, but to https://bugs.kde.org/show_bug.cgi?id=224827 Confirming on KDE 4.4.0, Fedora 12. My solution: sudo chmod -x /usr/bin/nspluginviewer Flash still works.^^ I still see this problem. QT_NO_GLIB=1 helps, but makes nspluginviewer crash often and also makes the Phonon GStreamer backend to not work. Did the fix in comment #24 ever make it into 4.4.x? Woops, thanks for reminder. Will do it today for 4.4.3. But, again, it only helps with wakeups, not with the 100% issue, which is different. This seems to also happen to me with Firefox, not just Konqueror. Same process, npviewer. It eats a lot of CPU for an odd reason... Indeed, this seems to be fixed in KDE SC 4.5 beta 2 (4.4.82). Thanks a lot to the developers! Can anyone else please confirm that it is fixed? I wanted to pipe up to say that this appears to have Regressed. I am using 12.04.3 LTS Kubuntu, KDE 4.11.0. Does not seem to make a difference which flash player is used (11.2, 11.8 tried), happens frequently, seeming randomly, kwin locks up, have to restart kwin in order to get valid cpu usage. I cannot confirm this issue is isolated to flash player either, but it seems to be the most noticeable instance. I would be happy to provide more details if anyone needs to ask something of me. Flash and Netscape plugins are no longer supported. |
Version: (using KDE 4.2.0) Installed from: Debian testing/unstable Packages nspluginviewer regularly hogs the CPU, probably after visiting a page with Flash content. (I am using Debian's flashplugin-nonfree 1:2.4, i.e. Adobe's flash plugin.) But what is worse, the nspluginviewer process is usually left behind when the browser tab in question is closed, thus requiring me to kill it manually. strace output from the nspluginviewer process amounts to some 300 lines per second of this sort: 14:09:24 read(8, 0x66ed94, 4096) = -1 EAGAIN (Resource temporarily unavailable) 14:09:25 select(18, [17], [17], NULL, NULL) = 1 (out [17]) 14:09:25 writev(17, [{"7\30\5\0!D`\10\236\2`\10\0\0\1\0\0\0\0\0\214\3\n\0\236\2`\10!D`\10\330"..., 68}, {NULL, 0}, {""..., 0}], 3) = 68 14:09:25 read(17, 0x72ccc4, 4096) = -1 EAGAIN (Resource temporarily unavailable) 14:09:25 poll([{fd=3, events=POLLIN}, {fd=16, events=POLLIN}, {fd=8, events=POLLIN}, {fd=17, events=POLLIN}], 4, 0) = 0 (Timeout) 14:09:25 read(8, 0x66ed94, 4096) = -1 EAGAIN (Resource temporarily unavailable) 14:09:25 read(8, 0x66ed94, 4096) = -1 EAGAIN (Resource temporarily unavailable) 14:09:25 read(17, 0x72ccc4, 4096) = -1 EAGAIN (Resource temporarily unavailable) 14:09:25 poll([{fd=3, events=POLLIN}, {fd=16, events=POLLIN}, {fd=8, events=POLLIN}, {fd=17, events=POLLIN}], 4, 0) = 0 (Timeout) 14:09:25 read(8, 0x66ed94, 4096) = -1 EAGAIN (Resource temporarily unavailable) 14:09:25 read(8, 0x66ed94, 4096) = -1 EAGAIN (Resource temporarily unavailable) 14:09:25 read(8, 0x66ed94, 4096) = -1 EAGAIN (Resource temporarily unavailable) 14:09:25 poll([{fd=8, events=POLLIN}], 1, 0) = 0 (Timeout) 14:09:25 read(8, 0x66ed94, 4096) = -1 EAGAIN (Resource temporarily unavailable) 14:09:25 read(17, 0x72ccc4, 4096) = -1 EAGAIN (Resource temporarily unavailable) 14:09:25 poll([{fd=3, events=POLLIN}, {fd=16, events=POLLIN}, {fd=8, events=POLLIN}, {fd=17, events=POLLIN}], 4, 0) = 0 (Timeout) 14:09:25 read(8, 0x66ed94, 4096) = -1 EAGAIN (Resource temporarily unavailable) 14:09:25 read(8, 0x66ed94, 4096) = -1 EAGAIN (Resource temporarily unavailable) 14:09:25 read(17, 0x72ccc4, 4096) = -1 EAGAIN (Resource temporarily unavailable) 14:09:25 poll([{fd=3, events=POLLIN}, {fd=16, events=POLLIN}, {fd=8, events=POLLIN}, {fd=17, events=POLLIN}], 4, 0) = 0 (Timeout) 14:09:25 read(8, 0x66ed94, 4096) = -1 EAGAIN (Resource temporarily unavailable) 14:09:25 read(8, 0x66ed94, 4096) = -1 EAGAIN (Resource temporarily unavailable) 14:09:25 read(8, 0x66ed94, 4096) = -1 EAGAIN (Resource temporarily unavailable) 14:09:25 poll([{fd=8, events=POLLIN}], 1, 0) = 0 (Timeout) 14:09:25 read(8, 0x66ed94, 4096) = -1 EAGAIN (Resource temporarily unavailable) 14:09:25 read(17, 0x72ccc4, 4096) = -1 EAGAIN (Resource temporarily unavailable)