Description of problem: Naughty gnash. I left firefox open to the webpage: http://www.timesonline.co.uk/tol/comment/columnists/ben_macintyre/article2002699.ece while doing other things. Eventually my computer stopped responding to my keyboard, and the mouse became sluggish. I had to ssh in from another computer to find out the problem is gnash was eating all my memory and cpu. I have 2 GB of regular memory and 4 GB of swap, 4 cpu's (shows up as 8 cpu's due to hyperthreading). Gnash brought the whole compute to a standstill. Version-Release number of selected component (if applicable): gnash-0.8.0-1.fc7 How reproducible: Haven't tried. Steps to Reproduce: 1. Open http://www.timesonline.co.uk/tol/comment/columnists/ben_macintyre/article2002699.ece in firefox and wait. Additional info: As a workaround to avoid this problem in the future I did: mv /usr/bin/gnash /usr/bin/gnash.real Then I created a /usr/bin/gnash script as follows: #!/bin/bash ulimit -H -m 256000 ulimit -H -v 256000 exec /usr/bin/gnash.real "$@" However, I expect that gnash using so much memory indicates a serious flaw in gnash itself, not just a need for ulimit settings. I also set higher value ulimits for firefox, just to be on the safe side.
Hmmm. It looks like the ulimits are not having an effect. 13706 docbill 15 0 900m 580m 11m S 53 30.8 3:29.89 gnash.real BTW. It looks like all this memory and CPU usage is to display a small vonage ad.
Bug #220657 makes this problem difficult to work around, but I did find the ulimit -v flag works from zsh (not from bash). So the following does work as a workaround: #!/bin/zsh ulimit -H -v 524288 /usr/bin/gnash.real "$@" Of course gnash is still broken. It looks like it is not reclaiming garbage collected memory. But at least this allows it to be used a very short while, without bringing down the whole machine. If I had a machine with less than 2GB of ram, I would probably just uninstall gnash until it is fixed.
There may have been some progress on that upstream with the addition of a garbage collector. Could you please try to reproduce with upstream cvs?
If you can provide a reference to the repository, I can certainly try it. Perhaps in the mean time, it would make sense to revert back to the previous version of gnash, as this version is bad enough, many non-technical people would dump the whole distribution. Bill
I found the upstream cvs tree, and did a checkout of tonights source tree. I used the following to build: cd gnash ./autogen.sh mkdir -p ../gnash-build cd ../gnash-build ../gnash/configure --enable-renderer=opengl --enable-media=GST \ --enable-plugin --with-plugindir=/usr/lib64/mozilla/plugins make CFLAGS="-pipe -O2" CXXFLAGS="-pipe -O2" -j 10 At after a building a few minutes, make reported some build errors. I find this is common when using -j 10 on a Makefile that is not designed for it. So I finished with: make CFLAGS="-pipe -O2" CXXFLAGS="-pipe -O2" sudo make install I find the current CVS version is much more stable, and actually works correctly on the web page I referenced above. e.g. This time when I browsed to the url, there were three flash ads. All three seem to render correctly, and with the telus one, I watched a pool of fish chase my mouse. All the while the memory usage for all three processes stayed steady. The CPU utilization was high while displaying the ads, but when I background the tabs utilization for each fell below 6%. I would definitely recommend, either updating the package, or finding what fixes were applied to gnash and back porting them. Bill
A new upstream release is on the way, I'll package it once it is out. In any case I consider gnash still quite immature and buggy, users that want to use it should know about that.
gnash-0.8.1-2.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.