bugGnash - The GNU Flash player - Bugs: bug #26097, gnash started in pause-mode uses...

 
 

bug #26097: gnash started in pause-mode uses insane amounts of CPU

Submitter:  Øyvind Sæther <xiando>
Submitted:  Mon 06 Apr 2009 10:55:34 AM UTC
Votes: 5
 
Category:  plugin Severity:  3 - Normal
Release:  None Status:  None
Privacy:  Public Assigned to:  vipw
Open/Closed:  Open
* Mandatory Fields

Add a New Comment Rich Markup
   

Mon 04 Jan 2010 08:38:59 AM UTC, comment #4: 

Many thanks for the information. As I suggested months ago, it's a problem specific to the Qt plugin. This is the kind of bug report that is necessary to have bugs fixed.

The function that strace shows repeatedly is:
QX11EmbedWidget::eventFilter(QObject*, QEvent*)

I will assign this to vipw, as he knows more about the Qt plugin than anyone else and may have some suggestions.

Benjamin Wolsey <bwy>
Group Member
Sun 03 Jan 2010 11:37:20 PM UTC, comment #3: 

I should have added that the flash content windows show pixel crap, i.e. a strong hint that repainting is broken.
Likely during pause mode we get a paint notification (invalidated window region), gnash doesn't handle it since it's paused, the GUI environment resends the paint notification, again gnash doesn't do anything, rinse, repeat.
IOW the implementation of the "Click to Play" button functionality is buggy in that it doesn't take into account basic invalidated region redrawing requirements.
Or at least that's my very remote suspicion (without any specific debugging since my environment installation doesn't provide the means).

Frankly this is now ~ the third time in about 2 years that due to severe gnash performance issues I'm torn between keeping gnash installed (and thus keeping Flash compatibility, with REALLY painful amounts of CPU consumed) or simply removing everything and living a peaceful life (without any Flash media, unfortunately).
This has now been going on since gnash has been available for installation on Debian. I had hoped that these issues would improve quickly, but so far not yet.

Thanks,

Andreas Mohr

Anonymous
Sun 03 Jan 2010 11:13:12 PM UTC, comment #2: 

Am having the same very severe issues here, on Debian gnash Version: 0.8.6-2 , konqueror Version: 4:4.3.2-1 .

Visiting e.g. http://www.voip-info.org/wiki/view/Asterisk+RealTime

shows 3 ads in the side bar with "Click to Play" visible (thus the only reasonable expectation would be for it to remain fully idle),
and all 3 burn tons of CPU (33% each in fact, as much as they can get, thus my poor P3/700 is killed and buried).

ltrace -f -p on a gnash shows repeated

_ZN15QX11EmbedWidget11eventFilterEP7QObjectP6QEvent(0x8321dc0, 0x8321e80, 0xbff2c4fc, 0x828c000, 0xbff2c248) = 0
_ZN7QWidget5eventEP6QEvent(0x8321e80, 0xbff2c4fc, 0xbff2c4fc, -1, 0x826e0c0) = 1
_ZN15QX11EmbedWidget11eventFilterEP7QObjectP6QEvent(0x8321dc0, 0x8321e80, 0xbff2c4fc, 0x828c000, 0xbff2c248) = 0
_ZN7QWidget5eventEP6QEvent(0x8321e80, 0xbff2c4fc, 0xbff2c4fc, -1, 0x826e0c0) = 1
_ZN15QX11EmbedWidget11eventFilterEP7QObjectP6QEvent(0x8321dc0, 0x8321e80, 0xbff2c4fc, 0x828c000, 0xbff2c248) = 0
_ZN7QWidget5eventEP6QEvent(0x8321e80, 0xbff2c4fc, 0xbff2c4fc, -1, 0x826e0c0) = 1
_ZN15QX11EmbedWidget11eventFilterEP7QObjectP6QEvent(0x8321dc0, 0x8321e80, 0xbff2c4fc, 0x828c000, 0xbff2c248) = 0
_ZN7QWidget5eventEP6QEvent(0x8321e80, 0xbff2c4fc, 0xbff2c4fc, -1, 0x826e0c0) = 1
_ZN15QX11EmbedWidget11eventFilterEP7QObjectP6QEvent(0x8321dc0, 0x8321e80, 0xbff2c4fc, 0x828c000, 0xbff2c248) = 0
_ZN7QWidget5eventEP6QEvent(0x8321e80, 0xbff2c4fc, 0xbff2c4fc, -1, 0x826e0c0) = 1
_ZN15QX11EmbedWidget11eventFilterEP7QObjectP6QEvent(0x8321dc0, 0x8321e80, 0xbff2c4fc, 0x828c000, 0xbff2c248) = 0
_ZN7QWidget5eventEP6QEvent(0x8321e80, 0xbff2c4fc, 0xbff2c4fc, -1, 0x826e0c0) = 1
_ZN15QX11EmbedWidget11eventFilterEP7QObjectP6QEvent(0x8321dc0, 0x8321e80, 0xbff2c4fc, 0x828c000, 0xbff2c248) = 0
_ZN7QWidget5eventEP6QEvent(0x8321e80, 0xbff2c4fc, 0xbff2c4fc, -1, 0x826e0c0) = 1
_ZN15QX11EmbedWidget11eventFilterEP7QObjectP6QEvent(0x8321dc0, 0x8321e80, 0xbff2c4fc, 0x828c000, 0xbff2c248) = 0
_ZN7QWidget5eventEP6QEvent(0x8321e80, 0xbff2c4fc, 0xbff2c4fc, -1, 0x826e0c0) = 1
_ZN15QX11EmbedWidget11eventFilterEP7QObjectP6QEvent(0x8321dc0, 0x8321e80, 0xbff2c4fc, 0x828c000, 0xbff2c248) = 0
_ZN7QWidget5eventEP6QEvent(0x8321e80, 0xbff2c4fc, 0xbff2c4fc, -1, 0x826e0c0) = 1
_ZN15QX11EmbedWidget11eventFilterEP7QObjectP6QEvent(0x8321dc0, 0x8321e80, 0xbff2c4fc, 0x828c000, 0xbff2c248) = 0
_ZN7QWidget5eventEP6QEvent(0x8321e80, 0xbff2c4fc, 0xbff2c4fc, -1, 0x826e0c0) = 1
_ZN15QX11EmbedWidget11eventFilterEP7QObjectP6QEvent(0x8321dc0, 0x8321e80, 0xbff2c4fc, 0x828c000, 0xbff2c248) = 0
_ZN7QWidget5eventEP6QEvent(0x8321e80, 0xbff2c4fc, 0xbff2c4fc, -1, 0x826e0c0) = 1
_ZN15QX11EmbedWidget11eventFilterEP7QObjectP6QEvent(0x8321dc0, 0x8321e80, 0xbff2c4fc, 0x828c000, 0xbff2c248) = 0
_ZN7QWidget5eventEP6QEvent(0x8321e80, 0xbff2c4fc, 0xbff2c4fc, -1, 0x826e0c0) = 1

Most likely some Qt event loop mechanism gone haywire, keeps sending updates.


gdb backtrace:

(gdb) bt
#0  0xffffe424 in __kernel_vsyscall ()
#1  0xb6103b47 in *__GI___poll (fds=0x83671e0, nfds=3, timeout=6) at ../sysdeps/unix/sysv/linux/poll.c:87
#2  0xb522275b in g_poll () from /lib/libglib-2.0.so.0
#3  0xb5215585 in ?? () from /lib/libglib-2.0.so.0
#4  0xb5215838 in g_main_context_iteration () from /lib/libglib-2.0.so.0
#5  0xb652f041 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
   from /usr/lib/libQtCore.so.4
#6  0xb67db305 in ?? () from /usr/lib/libQtGui.so.4
#7  0xb650283a in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#8  0xb6502c82 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#9  0xb65050d9 in QCoreApplication::exec() () from /usr/lib/libQtCore.so.4
#10 0xb673b917 in QApplication::exec() () from /usr/lib/libQtGui.so.4
#11 0x080a40ab in gnash::Kde4Gui::run() ()
#12 0x0809ed06 in gnash::Player::run(int, char**, std::string const&, std::string const&) ()
#13 0x0808a758 in main ()



Related strace output is:

clock_gettime(CLOCK_MONOTONIC, {138582, 941682432}) = 0
clock_gettime(CLOCK_MONOTONIC, {138582, 941881076}) = 0
read(7, 0x828c058, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
clock_gettime(CLOCK_MONOTONIC, {138582, 943241693}) = 0
poll([{fd=3, events=POLLIN}, {fd=8, events=POLLIN}, {fd=7, events=POLLIN}], 3, 7) = 0 (Timeout)
read(7, 0x828c058, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
clock_gettime(CLOCK_MONOTONIC, {138582, 951767197}) = 0
clock_gettime(CLOCK_MONOTONIC, {138582, 951971988}) = 0
read(7, 0x828c058, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
clock_gettime(CLOCK_MONOTONIC, {138582, 953314444}) = 0
poll([{fd=3, events=POLLIN}, {fd=8, events=POLLIN}, {fd=7, events=POLLIN}], 3, 7) = 0 (Timeout)
read(7, 0x828c058, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
clock_gettime(CLOCK_MONOTONIC, {138583, 461617}) = 0
clock_gettime(CLOCK_MONOTONIC, {138583, 9542264}) = 0
read(7, 0x828c058, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
clock_gettime(CLOCK_MONOTONIC, {138583, 30669814}) = 0
poll([{fd=3, events=POLLIN}, {fd=8, events=POLLIN}, {fd=7, events=POLLIN}], 3, 0) = 0 (Timeout)
read(7, 0x828c058, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
clock_gettime(CLOCK_MONOTONIC, {138583, 51523564}) = 0
read(7, 0x828c058, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
clock_gettime(CLOCK_MONOTONIC, {138583, 72054342}) = 0
poll([{fd=3, events=POLLIN}, {fd=8, events=POLLIN}, {fd=7, events=POLLIN}], 3, 0) = 0 (Timeout)


Boosting priority of this bug would be nice, it is annoying (and simply BROKEN) beyond belief.

Thanks,

Andreas Mohr

Anonymous
Mon 06 Apr 2009 11:24:25 AM UTC, comment #1: 

When I try that site (svt.se) with Gnash starting in pause mode in Firefox I get a brief peak of about 20% CPU while it downloads and parses, then 0% CPU on all four cores. Gnash is not doing anything at all. So for me at least this isn't reproducible on Firefox.

A possibility is that the qt4 plugin keeps requesting a full redraw, but this is just a guess, as I haven't looked at the code or tested in Konqueror.

Benjamin Wolsey <bwy>
Group Member
Mon 06 Apr 2009 10:55:34 AM UTC, original submission:  

gnash uses so much CPU-time that having a page with a flash open halts my computer to the point where it is impossible to do anything without closing the browser(s) or killing gnash-processes.

Starting gnash in "pause"-mode makes having a browser window with one flash thing almost alright, but the CPU usage is still high.

Opening a site with a whole lot of flash applets, such as svt.se, puts my computer to a halt even when pause mode is enabled.

Gecko-based browsers have flashblock, which means that it is possible to use gnash with those since flashblock prevents gnash from trying to use ten times available CPU-power to do .. well, NOTHING when it's started in pause-mode.

There is no flashblock for Konqueror. This means that my choice right now is to not compile KDE4 support for gnash or buy a supercomputer which has enough CPU usage to handle gnash's requirements for showing an empty window with a "click to play" button.

Could some developers PLEASE look into why gnash want to eat  all available CPU-time to show the "click to play" botton?

It would be really great if the "start gnash in pause"-mode could make gnash not want to use 100% CPU when it's started in this mode. I would get it if gnash was prefetching the flash content or something when it is eating CPU in pause-mode, but that isn't the case, a gnash in pause will keep on eating CPU forever. Ideally it should not use CPU-time at all when it is started in the pause-mode.

Thanks.

Relevant bugs: #19901 ("Confirmed") and #21035 ("Fixed", but really isn't)

Øyvind Sæther <xiando>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by stuart10 (Voted in favor of this item)
  • -email is unavailable- added by bwy (Posted a comment)
  • -email is unavailable- added by xiando (Submitted the item)
  •  

    There are 5 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-03-31 stuart10 Carbon-Copy- Added stuart10
    2010-01-04 bwy Assigned toNone vipw
    2009-04-06 bwy CategoryNone plugin

    Back to the top

    Powered by Savane 3.13-caa5.
    Corresponding source code