User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030319 Debian/1.3-3 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030319 Debian/1.3-3 Starting with Mozilla 1.3, the acrobat reader plugin (5.05/Linux) uses 100% CPU when viewing PDFs. Viewing the PDF in a separate Acrobat Reader window does not produce this effect. This happens for all PDFs I've tried. I have not tried with other versions of Reader. The following bug might be related: http://bugzilla.mozilla.org/show_bug.cgi?id=198230 Reproducible: Always Steps to Reproduce: 1. Install Abobe Acrobat Reader 5 as a plugin 2. Go to any PDF file 3. 100% CPU for the acrobat process. Actual Results: Acrobat uses 100% CPU, making system response time slow. Expected Results: Acrobat should not have to use 100% CPU.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 Red Hat 8.0 Same for me with the www.gurulabs.com 5.06 plugin RPM.
Still happens with the Red Hat Rawhide 1.4 RPMs (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/2003061). I believe this is a gtk+ version.
The same issue also occurs on Windows 2000: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Could someone change the OS flag to all?
Problem persists with Moz 1.4 final (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630) and Acrobat plugin 5.07.
Same behaviour with mozilla 1.4 (Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.4) Gecko/20030701) and Acrobat 5.0.8 When mozilla is launched from the shell, the following message appears Warning: Actions not found: addBookmark, viewBookmark, copy, undefined-key, find, findAgain, history, loadImages, openURL, mailNew, new, openFile, print, exit, reload, saveAs, paste, delete, cut, undo, historyItem, back, forward, abort, PageUp, PageDown Warning: Actions not found: ManagerGadgetNextTabGroup, ManagerGadgetPrevTabGroup, DrawingAreaInput, addBookmark, viewBookmark, copy, undefined-key, find, findAgain, history, loadImages, openURL, mailNew, new, openFile, print, exit, reload, saveAs, paste, delete, cut, undo, historyItem, back, forward, abort, PageUp, PageDown Warning: No action proc named "ManagerGadgetArm" is registered for widget "form"
I deleted the plugin nppdf.so (plugin from adobe) from the plugins directory. Acrobat reader is then launched by plugger4.0. In this case, CPU is relaeased once the file is loaded and displayed in the Mozilla window. Unfortunately only one file can be displayed at a time.
Just installed the mozilla-1.4.1-10 RPMs from Red Hat Rawhide, and it seems like the problem no longer occurs. CPU runs flat out while loading, but once the document is loaded, CPU drops off again.
Upgrading to the Rawhide mozilla-1.4.1-10 RPM doesn't fix the problem for me, although I am running a bastardized Red Hat 9 with glibc and several other updated RPM's from mid-beta-cycle versions of Severn.
I had assumed this was due to gcc-3.2/3.3 builds; I don't think this was happening on the contributed red hat 7.3 rpm's of mozilla-1.4.
Just as another data point, the mozilla.org RPMs for Mozilla 1.5/Red Hat 9 also work fine. My system is fully up2date Red Hat 9 stock (and Acrobat Reader is 5.08 from gurulabs.com). It would be interesting to know if it happens on the (full) latest Severn test release.
Did a little bit of stepping in GDB for the mozilla-bin process. Without full debug symbols and knowledge of Mozilla/GTK2/X internals, I can't tell much, but there seems to be an endless X event processing loop going on, involving some sort of Focus/Update/Expose events. Maybe somewhere there is a buggy event handler that posts other events during its processing. Perhaps this is unique to GTK2.
Spoke to Bill Wallace and the issue he is seeing on Windows was different from then one I am seeing on Linux. His browser crashed and stopped responding, mine ate 100%CPU but continued to respond and stopped eating CPU when I closed the window with the PDF or went to another URL that didn't have a PDF.
Bill's problem stopped happening after upgrading Mozilla and Acrobat.
I'm seeing this bug in Linux with Mozilla 1.4, although for me the X process is using 80% CPU, not the acroread process. Anyone else seeing this?
Yes, for me the X process eats most of the CPU. killall -STOP mozilla-bin causes the CPU usage to pause and you can continue to use the acroread child window normally.
This occurs on current trunk builds and 1.4.1 (Stable) using Acrobat 5.0.8. However, the processor is released after the PDF is loaded. It seems like the plugin just eats the entire CPU for rendering (on a 350 PentiumII). This may be just an issue with the Acrobat plugin now.
-> WFM after extensive testing here are the results. System: PentiumII 350 MHz, 256 MB RAM, Gentoo Linux 1.4 (current on everything), IceWM 1.2.13 (from Portage) Loading a PDF from Acrobat (standalone): 1-2 seconds of 100% CPU usage Loading a PDF from current trunk: 2-3 seconds Loading a PDf from Mozilla 1.4.1 (Stable Branch): 2-3 seconds Confirmed results with other testers. Feel free to reopen if you still see this issue, that is the CPU is never released and not the above results.
I concur with #17. Sounds like normal behavior for PDF files. They simply require a good chunk of CPU to render. Especially complex ones.
I am definitely still observing the problem on fedora's mozilla-1.4.1-18. system is fedora core 1 with all other current updates applied. I strongly believe this to be a gtk2-specific plugin problem. if you did not at least do your testing on a gtk2 build you are comparing apples and oranges with the people that seem to be experiencing this. I have done enough investigation with gdb to confirm that this is more than just a rendering issue. What happens is that messages are passed and forth endlessly between the mozilla process and the X server, causing the X server to consume 100%CPU. Note that the actual rendering is handled by the acroread child process and this is idle when I am seeing the problem. Even for simple PDF's on my system the CPU is not released even after rendering is complete. Please do not close this as WORKSFORME unless you have actually tested with a gtk2 buildconfig. Can you testers confirm your buildconfigs? My about:buildconfig is as follows, Build platform target i686-pc-linux-gnu Build tools Compiler Version Compiler flags gcc gcc version 3.3.2 20031022 (Red Hat Linux 3.3.2-1) -Wall -W -Wno-unused -Wpointer-arith -Wcast-align -Wno-long-long -pedantic -g -pthread -pipe c++ gcc version 3.3.2 20031022 (Red Hat Linux 3.3.2-1) -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-long-long -pedantic -g -fshort-wchar -pthread -pipe -I/usr/X11R6/include Configure arguments --prefix=/usr --libdir=/usr/lib --enable-optimize=-O2 --disable-debug --enable-pie --with-default-mozilla-five-home=/usr/lib/mozilla-1.4.1 --disable-strip-libs --disable-tests --enable-xinerama --enable-nspr-autoconf --enable-extensions=default,irc --without-mng --enable-crypto --disable-xprint --without-system-nspr --with-system-zlib --enable-default-toolkit=gtk2 --disable-freetype2 --enable-xft --mandir=/usr/share/man
Reopening and updating summary to more accurately reflect the problem
CC'ing Christopher Blizzard as it involves GTK2
reproduced this on tonight's mainline (vanilla--no Fedora specific patches) My system is fully up2date Fedora 1 and has these libraries: kernel-2.4.22-1.2149.nptl atk-1.4.0-1 expat-1.95.5-3 fontconfig-2.2.1-6.1 freetype-2.1.4-5 glib2-2.2.3-1.1 glibc-2.3.2-101.4 gtk2-2.2.4-5.1 libgcc-3.3.2-1 libstdc++-3.3.2-1 pango-1.2.5-1.1 XFree86-libs-4.3.0-42 zlib-18.104.22.168-2 Mozilla is: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7a) Gecko/20040114 about:buildconfig Build platform target i686-pc-linux-gnu Build tools Compiler Version Compiler flags gcc gcc version 3.3.2 20031022 (Red Hat Linux 3.3.2-1) -Wall -W -Wno-unused -Wpointer-arith -Wcast-align -Wno-long-long -pedantic -pthread -pipe c++ gcc version 3.3.2 20031022 (Red Hat Linux 3.3.2-1) -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-long-long -pedantic -fshort-wchar -pthread -pipe -I/usr/X11R6/include Configure arguments --enable-default-toolkit=gtk2 --disable-freetype2 --enable-xft --disable-xprint --disable-tests
I can confirm the same behaviour. The triggering thing is gtk2 build. Anything else has no problems. Tried and tested in RedHat 9 and Fedora 1 with various versions of mozilla up until 1.6.
Did some investigation. Turns out Mozilla is constantly repainting itself, probably due to receiving a lot of OnExposeEvents curtesy of callback from gdk (of full main window and some subwindows?). This happens even while being fully hidden behind other windows. Acroread plugin seems not to do much at all while mozilla is redrawing itself. Could even be a bug in gdk/gtk (why is it sending GDK_EXPOSE's? though it could be triggered by something else too). Anyway, out of my depth here... Suggestions? I am willing to help track this down.
Thought I'd mention that this problem persists in the Mozilla 1.6.0 RPM in Fedora testing branch. Below is the buildconfig information. Build platform target i686-pc-linux-gnu Build tools Compiler Version Compiler flags gcc gcc version 3.3.2 20031218 (Red Hat Linux 3.3.2-5) -Wall -W -Wno-unused -Wpointer- arith -Wcast-align -Wno-long-long -pedantic -g -pthread -pipe c++ gcc version 3.3.2 20031218 (Red Hat Linux 3.3.2-5) -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor- privacy -Wno-long-long -pedantic -g -fshort-wchar -pthread -pipe -I/usr/X11R6/include Configure arguments --prefix=/usr --libdir=/usr/lib --enable-optimize=-O2 --disable-debug --with-default- mozilla-five-home=/usr/lib/mozilla-1.6 --disable-strip-libs --disable-tests --enable-xinerama --enable-nspr-autoconf --enable-extensions=default,irc --without-mng --enable-crypto -- disable-xprint --without-system-nspr --with-system-zlib --enable-default-toolkit=gtk2 -- disable-freetype2 --enable-xft --mandir=/usr/share/man
*** Bug 233924 has been marked as a duplicate of this bug. ***
I can easily reproduce this issue on a Red Hat Workstation 3 machine, using the 1.6 rpms, acroread-5.0.6-1. CPU running less than 1% on average. Opened a simple PDF - one page, text only - and it spiked to about 70% and stayed there. Hitting the back button dropped the CPU back down instantly. X is taking close to 50% of the processing time, mozilla less than 15%, and acroread not enough to register above 0. X continues to crank the CPU even when I'm on a different tab in mozilla, and when I minimize mozilla to the panel (or to its task bar). thx anthony
I am once again getting the behavior where the CPU pegs as long as the PDF is being viewed (i.e., it no longer stops once the page is loaded). Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040124 Fully updated Fedora Core 1 (including XFree86-4.3.0-55, gnome-libs-22.214.171.124.90-36). Anything else about versions of things I can tell you?
I, too, get this. It's been like this for a very long time for me, since about 2002. I would love to see this thing resolved (I would also like to see a new Reader version from Adobe, but that's less likely!).
Also in GTK buid of Firefox 0.8. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040211 Firefox/0.8
I think I now understand why I was seeing the plugin appear to work correctly. Here's my story. I decided to back out the acrobat plugin, so I deleted nppdf.so from /usr/lib/mozilla/plugins/ and /usr/lib/firefox/plugins/. That caused the PDF display to revert to xpdf, invoked as a helper in a separate window. On another machine I have, xpdf is invoked in a browser window. I realized that that's the behavior when xpdf is invoked through mozplugger, so I installed mozplugger on the machine I was working on. On viewing a PDF, I found I was seeing it in a browser window in acrobat reader, and there was no runaway CPU. (I had not uninstalled acrobat reader entirely, just unlinked the plugin symlinks). It turns out mozplugger invokes acrobat reader and swallows it. So acrobat can be used with mozplugger without exhibiting the bad behavior, but using the native plugin does exhibit the behavior. Sorry I didn't realize that on some of my earlier posts indicating that I wasn't seeing the bug. Hope this observation provides a clue and/or a workaround.
Problem also exists on Debian Unstable. Mozilla including all derivates (Galeon, Epiphany) is affected as well as mozilla-firefox. All are built against Gtk+2.
I have been having this same problem on Windows for the last several Mozilla builds since 1.4 RC1 (beta, RC and released versions) and for both Acroread and Acrobat professional at versions 5 and 6 on both Win2k and WinXP. The instant that a PDF is selected for viewing in Mozilla, things are still OK. Within seconds of the Acrobat or Acroread process showing up, Mozilla consumes CPU to such an extent that all other Normal or less processes are starved. This causes the Acrobat process to take a very very long time to do anything. As a temporary workaround, I go into task manager and set Mozilla to "Below Normal" scheduling. At that point, Acrobat can continue loading it's plugins and doing it's init. Linux users might be able to renice Mozilla to allow acrobat to finish initialization. Once Acrobat is ready to begin displaying the PDF, Mozilla stops consuming high CPU and I can set it back to normal. If Acrobat is running already, then this does not occur. This seems to imply that Mozilla is in a loop waiting for some sort of response from the acrobat plugin and that response is only given when the acrobat program is fully started. I have the same problem in Internet Explorer 6 SP1 on both 2k and XP, which seems to imply it may be related to the acrobat plugin, or maybe there is a common calling method between the browsers. The problem is worse when acroread is loading pieces of a PDF rather than the whole PDF. While it's waiting for network, Mozilla hangs; however, I'm not sure if it is still Mozilla consuming CPU at that point because I try to avoid split PDFs. Everything is fine if a PDF is shell launched. This seems to be a duplicate bug. The bugs I see which seem to match this are:<BR> <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=198954">198954</a><BR> <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=219987">219987</a><BR>
I am convinced that the Windows behaviour is completely unrelated to this bug. This bug is GTK-only. Everything loads and works fine, but the CPU usage is high. The bug has been said to not exist if Mozilla is compiled without GTK support.
Updated to Acroread 6.0.1 and problem still exists. Acroread only hung about 15 seconds this time, and loaded fewer of it's own plugins on init; however, it was recently installed and run, so it was likely fully cached. After closing acroread, copying large files to overwrite cache, and restarting, the hang condition was still very short, indicating that the adobe code has optimized it's initialization procedure severely. So what it seems is that if a plugin takes more than a couple of seconds to start, the Mozilla's CPU hog condition will cause that plugin to become CPU starved, and Mozilla's CPU hog condition seems to be because the plugin hasn't finished loading yet. Again, I see the same situation with IE6; however, For all I know, IE6 uses mozilla-like code to call plugins. A good test would be to see if there are other plugins that take a long time to initialize and if so, do they do the same thing to Mozilla? Why is Mozilla spinning it's wheels? Is it effectively calling an I/O routine in the plugin that blocks the main thread while it waits for response? I know I used to have problems with Mozilla hanging on web/html accesses when I would have network hangs, but I don't recall having that happen recently and don't know if that is related or not. I'm sorry I don't have the tools or experience to isolate this to plugin calling methods versus plugin itself. The problem might simply be explained away with a policy of "plugins should start in 5 seconds or less to prevent browser hangs", or maybe someone still wants to look further into it. Either way, it doesn't presently seem to be a serious problem when using Acro 6.0.1. Current env: Thinkpad T21, Pentium III 800, 512MB PC133, S3 Graphics Savage/IX 1014 Microsoft Windows 2000 5.00.2195 Service Pack 4 C4EB 4.0 (OPK B2195 SP4) Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040421 Adobe Reader 6.0 Version 6.0.1 11/3/2003, AGM Version 4.10.50, CoolType version 4.13.42, Core Version 6.1, JP2K Version 1.0.22891, ADM Version 3.01x1 ------------------ I saw the colliding update just above. I don't know about how GTK affects plugin loading on Linux and whether that is analagous to any non gtk Windows calls. I re-posted my updates in the other bug, so if it's easier to ignore the above, that's OK.
I am seeing this on Mozilla 1.6 built on RHEL 3. X takes about 70% CPU and Mozilla takes the other 30%. What's the update on this? Does Mozilla 1.7 fix this issue? Build platform target i686-pc-linux-gnu Build tools Compiler Version Compiler flags gcc gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-24) -Wall -W -Wno-unused -Wpointer-arith -Wcast-align -Wno-long-long -pedantic -g -pthread -pipe c++ gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-24) -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-long-long -pedantic -g -fshort-wchar -pthread -pipe -I/usr/X11R6/include Configure arguments --prefix=/usr --libdir=/usr/lib --enable-optimize=-O2 --disable-debug --with-default-mozilla-five-home=/usr/lib/mozilla-1.6 --disable-strip-libs --disable-tests --enable-xinerama --enable-nspr-autoconf --enable-extensions=default,irc --without-mng --enable-crypto --disable-xprint --without-system-nspr --with-system-zlib --enable-default-toolkit=gtk2 --disable-freetype2 --enable-xft --mandir=/usr/share/man
I believe it is more of a bandwitch problem. Acrobat can't have proper bandwitch to get the pdf document. Cause it's initialized and waiting for the document to load.
It is NOT only a bandwidth issue. I can reproduce this issue retrieving a PDF from a webserver on the same subnet as my workstation. Even after Acrobat displays the document (it's fully downloaded), the CPU is pegged at close to 100%.
Brian, I'm not sure if he was referring to network bandwidth or some other kind of bandwidth...
It has nothing to do with any sort of bandwidth. It is a specific bug in the GTK2 code dealing with plugins.
The Fedora package for 1.7.2 still suffers from this problem. I compiled the 1.7.2 source package on a fully updated Fedora Core 1, and the Acrobat plugin it works without problems on it. The options were: export CXXFLAGS="-march=pentium3 -Os" export CFLAGS="-march=pentium3 -Os" export LIBIDL_CONFIG=/usr/bin/libIDL-config-2 ac_add_options --enable-calendar ac_add_options --disable-debug ac_add_options --enable-xft ac_add_options --enable-crypto ac_add_options --prefix=/opt/mozilla-1.7.2 The Fedora package mozilla-1.7.2-0.2.0 includes some patches, so source config options are not the only difference.
Is this new binary still linked against GTK?
You mean GTK2. And yes, it still is. The nature of this bug is unchanged in 1.7.x - it works on GTK1, does not work on GTK2.
Comment #41, the reason your build didn't exhibit this problem was because you did not make a GTK2 build.
Bug confirmed to still happen on Fedora Core 2. Mozilla version: mozilla-1.7.2-0.2.0 Acroread version: mozilla-acroread-5.0.9-1.1.fc2.dag acroread-5.0.9-1.1.fc2.dag Yes, mozilla is gtk2 enabled build.
I just spent a few hours debugging this problem. I don't have a patch yet, but I'll explain what we've discovered about it. The 100% CPU problem is being caused by a resize storm that's a result of interaction between the gtk socket code (gtksocket.c in the gtk source), the xtbin widget that implements the plug (as in plug/socket, not a mozilla plugin) and the plugin itself. It appears at first blush that the plugin is registering a handler for the xtbin shell and listening for ConfigureNotify events. On one of those events, it's resizing itself and the shell (which is owned by Mozilla *cough*) again, causing the gtksocket code to receive the ConfigureRequest event which queues a ConfigureNotify event for the plug which is delivered to the plug and then the entire process goes around again.
I spent the entirety of Friday on this problem and I managed to get the plugin displaying, but it's not pretty. (It also doesn't resize properly, among other things.) Basically the acrobat plugin is pretty terrible. It apparently gets its window size based on X events instead of through the plugin api. It apparently registers handlers on Mozilla's plugin windows and bases size changes and visibility changes based on those events instead of using the plugin api. Underneath the covers the Gtk2 xtbin code uses an xembed gtk2 socket and xt-based plug to host plugins. Since the acrobat plugin apparently registers listeners for some of the X events on mozilla's window, it gets some of the internal communications between the plug and the socket and responds to it, causing the storms. Also, it never maps itself. I don't know what causes this exactly, but I have to brutally map the subwindows pretty late in the game to even get it to display. And it doesn't respond to resize events when that happens, even though I'm pretty sure the plugin is getting resize requests through the plugin api. I can add a bunch of hacks to our code that _might_ get this plugin working but also will likely add regressions to our code. I'm not happy about this. It would be nice if we could get adobe to fix their plugin to be a bit more sane.
Chris: thanks so much for looking at this. I frequently wonder if Adobe has plans to make their 6.x viewer available on Linux. If it's going to happen, I wonder if they make considerations like this, if someone there sees these bugs. It's too bad Adobe is such a closed company. Their silence is deafening.
Why not log a feature request? http://www.adobe.com/support/feature.html
done. everyone make a feature request and maybe they will listen.
Another possible solution would be Xpdf http://www.foolabs.com/xpdf/ as Mozilla plug-in. Comments anyone?
Feature request added on my part too. Xpdf does not allow form filling as Acrobat reader does. Is there any other pdf reader/viewer in Linux that allows form filling?
Also exists on Fedora Core 2 in both Mozilla and Firefox. mozilla-1.7.3-0.2.0 firefox-0.9.3-0.fdr.4 acroread-5.0.9-1.1.fc2.dag mozilla-acroread-5.0.9-1.1.fc2.dag Mozilla and firefox are both gtk+2 builds in FC2.
(In reply to comment #53) > Also exists on Fedora Core 2 in both Mozilla and Firefox. > mozilla-1.7.3-0.2.0 > firefox-0.9.3-0.fdr.4 > acroread-5.0.9-1.1.fc2.dag > mozilla-acroread-5.0.9-1.1.fc2.dag > Mozilla and firefox are both gtk+2 builds in FC2. Also in Mozilla 1.7.2 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803. The CPU doesn't peg on initial open of a PDF page. But, once I have openned a PDF, if I suspend the laptop overnight then resume, my CPU is pegged at 100% (by mozilla according to windows task manager but it only happens with acrobat files). Note: I feel like I have seen similar behavior also from openning lots of tabs in the same browser overnight, but it is possible that this later behavior is because there is a higher chance that one of those tabs is acrobat.
Considering the ubiquity of PDF files, the lack of an open-source viewer with equivalent functionality, and the fact that Adobe hasn't addressed this problem for (at least) 19 months, perhaps it would be wise to temporarily work around Adobe's bugs by kludging Mozilla? If the kludges are activated only for this plugin ("nppdf.so"), the risk of regressions is limited.
I've heard that Adobe's upcoming Acrobat 7 plug in targets a fix for this
Any details on where you heard about this and when the release is scheduled?
For the time being I use gpdf through the mozilla-bonobo plugin. It is o.k. for many PDF files although it is not (yet) a full replacement for Acroread. Has anyone ever tried to contact Adobe? If someone from the Mozilla Foundation did so, they probably cannot but listen.
*** Bug 253868 has been marked as a duplicate of this bug. ***
You will note that if you go and download the adobe reader: http://www.adobe.com/products/acrobat/readermain.html That the current version is now 5.0.10. This version fixes the 100% CPU problem.
I don't object to the closing of this bug, but I'd like to suggest that a note to this effect (or rather, the solution) be added to the release notes.
*** Bug 239414 has been marked as a duplicate of this bug. ***
*** Bug 246560 has been marked as a duplicate of this bug. ***
*** Bug 201211 has been marked as a duplicate of this bug. ***
(In reply to comment #60) > You will note that if you go and download the adobe reader: > > http://www.adobe.com/products/acrobat/readermain.html > > That the current version is now 5.0.10. This version fixes the 100% CPU problem. (In reply to comment #61) > I don't object to the closing of this bug, but I'd like to suggest that a note > to this effect (or rather, the solution) be added to the release notes. I'm not convinced this is fixed in Acreread 5.0.10 (Mozilla 1.7 plugin). Even when acroread itself doesn't reach 100% on `top`, the acroread is still a top syscall user when idly displaying a pdf. Here is what an idle acroread plugin is doing approximately every 10 seconds (dtrace) UnixWorkCallbackProc 1 XtAppAddWorkProc 1 JS_ArenaFinish 1 JS_ArenaRelease 1 js_SweepAtomState 1 js_MarkAtomState 1 js_FlushPropertyCache 1 js_GC 1 js_ForceGC 1 JS_GC 1 ESDoGC 1 AESCreateESContext 1 ESContextGetPrimary 1 IsGCEnabled__Fv 1 DoGarbageCollect__FPv 1 miTimeSecs 2 __time 2 js_ContextIterator 2 time 2 JS_FinishArenaPool 3 JS_HashTableEnumerateEntries 3 FreeArenaList 4 memset 5 gc_root_marker 11 gc_mark_script 40 UnixIdleTimerCallbackProc 618 .udiv 618 XtAppAddTimeOut 618 QueueTimerEvent 618 UnixConvertTicksToMillis 618 CallWorkProc 619 _XFlushInt 619 _XFlush 619 UnixAppGetAppContext 619 UnixIdleRegisterCallback 619 EWHIdleProc 619 ASFileIsAnyFileBusy 619 AVAppIsBusy 619 AVAppIdle 619 DoOtherSources 619 ASGetpASExceptionStackTop 620 js_atom_sweeper 699 js_atom_marker 699 InitTimes 1237 _XtWaitForSomething 1237 IoWait 1237 AdjustTimes 1237 InitFds 1237 ioctl 1238 DebugAssertion 1238 ASTicks 1238 .div 1238 _X11TransSocketBytesReadable 1238 _X11TransBytesReadable 1238 _XEventsQueued 1238 XEventsQueued 1238 _pollsys 1242 pselect 1242 select 1242 _save_nv_regs 1242 __pollsys 1242 gc_find_flags 2084 gc_mark 2097 gettimeofday 3093 gc_mark_atom 4047 Acroread itself may not be top cpu user, but it seems to be inducing other processes and the kernel into doing alot of unecessary work.
Yes, but that is their bug and all of that activity does not cause the system to become unresponsive like when it was really pushing the CPU.