Description of problem:
Naughty gnash. I left firefox open to the webpage:
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):
Steps to Reproduce:
in firefox and wait.
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:
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
ulimit -H -v 524288
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.
I found the upstream cvs tree, and did a checkout of tonights source tree. I
used the following to build:
mkdir -p ../gnash-build
../gnash/configure --enable-renderer=opengl --enable-media=GST \
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
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
I would definitely recommend, either updating the package, or finding what fixes
were applied to gnash and back porting them.
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.