Bug 131732 - (IT_47024:IT_45974) Use of Acroread plugin causes Mozilla & X to use 100% of a CPU
Use of Acroread plugin causes Mozilla & X to use 100% of a CPU
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: mozilla (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Christopher Aillon
Ben Levenson
Depends On:
Blocks: 132991
  Show dependency treegraph
Reported: 2004-09-03 14:36 EDT by Mike Gahagan
Modified: 2007-11-30 17:07 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-01-18 16:52:36 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Mike Gahagan 2004-09-03 14:36:11 EDT
Description of problem:

Use of Acroread plugin causes Mozilla & X to use 100% of a CPU when it
should be idle or otherwise lightly loaded.

Version-Release number of selected component (if applicable):

Acroread plugin 5.08 & 5.09. Both the version from Adobe and our
packages in RHN (U2 & U3) show the same behavior.

How reproducible:

Always when configured as a plugin, never when used as a helper

Steps to Reproduce:
1. Install latest mozilla and acroread-plugin for RHEL3 from RHN
2. Open mozilla, point it to any pdf file
3. Open top or similar tool in a seperate window, observe that CPU is
100% utilized between X and mozilla processes. This occurs for the
entire time that the plugin is displaying the PDF in the active window
or tab.
Actual results:

Acroread itself seems well behaved, it consumes CPU as expected during
start-up/PDF file load, afterwards it drops off to basically zero
unless it is actually rendering/refreshing the document. The entire
time the pdf is displayed on the active window/tab, X and Mozilla will
consume an entire CPU's worth of cycles between them. This continues
until either the window is closed, another (non-PDF) page is loaded
with the same window or a different mozilla window/tab is placed in
the foreground.

Expected results:

No excessive CPU usage

Additional info:

I have verified that this is not a problem with plugins in general,
only Acroread. For example, the Java plugin functions as expected with
no excessive CPU usage except during initilization or from the Java
app itself. I have reproduced this reliably on x86 and x86_64. I tried
this on a system with a relatively slow video card and it is apperant
that the mozilla window (at least the top part where the URL input &
toolbar are) is constantly redrawing itself. The Acroread plugin
itself does not exhibit this behavior. Please review the mozilla.org
bug at the URL provided, lots of additional info there. This is
possibly a GTK2 bug. According to that report, this problem is not
reproduceable unless Mozilla is built against GTK2.
Comment 13 Jeff Needle 2004-12-15 10:39:52 EST
http://www.adobe.com/products/acrobat/readstep2.html now has 5.0.10, which has a
fix for this problem.
Comment 15 Christopher Blizzard 2004-12-16 11:13:12 EST
It appears to be in the tree for RHEL4 GA.  I don't think anyone has
updated it for any older releases yet.  Do you have a bug open for the
various release yet?
Comment 16 Dave Maley 2004-12-16 14:11:52 EST
This bug was opened for RHEL3.  Is there any need for another bug to
be opened?
Comment 17 Dave Maley 2005-01-04 11:07:33 EST
what's the status of getting a RHEL3 update for this?  will it make U5?
Comment 18 Havoc Pennington 2005-01-18 13:30:51 EST
Reopening and moving to caillon for RHEL3 backport.
Comment 19 Christopher Aillon 2005-01-18 16:16:15 EST
Isnt this fixed?  There was an errata for acroread in RHEL3 already
which should also resolve this.  Looks like 5.10 is in...
Comment 20 Dave Maley 2005-01-18 16:36:58 EST
Yup, looks good to me.  5.10 is available on RHN now and I've verified
that this version doesn't peg the CPU.  This can be considered closed.
Comment 21 Christopher Aillon 2005-01-18 16:52:36 EST

Note You need to log in before you can comment on or make changes to this bug.