Closed Bug 198954 Opened 21 years ago Closed 20 years ago

Acrobat Plugin uses 100% CPU on GTK2 Builds

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: mikael, Assigned: peterlubczynski-bugs)

References

Details

(Keywords: relnote) 

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.
Blocks: 198230
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.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
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
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Summary: acrobat plugin uses 100% CPU on mozilla 1.3 → Acrobat Plugin uses 100% CPU on GTK2 Builds
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-1.2.0.7-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-1.4.1.2.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.
Flags: blocking1.7?
Flags: blocking1.7? → blocking1.7-
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.
Status: REOPENED → RESOLVED
Closed: 21 years ago → 20 years ago
Resolution: --- → INVALID
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.
Keywords: relnote
*** 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.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.