Bug 131732 (IT_47024:IT_45974) - Use of Acroread plugin causes Mozilla & X to use 100% of a CPU
Summary: Use of Acroread plugin causes Mozilla & X to use 100% of a CPU
Alias: IT_47024:IT_45974
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: mozilla   
(Show other bugs)
Version: 3.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Christopher Aillon
QA Contact: Ben Levenson
URL: http://bugzilla.mozilla.org/show_bug....
Depends On:
Blocks: 132991
TreeView+ depends on / blocked
Reported: 2004-09-03 18:36 UTC by Mike Gahagan
Modified: 2007-11-30 22:07 UTC (History)
4 users (show)

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

Attachments (Terms of Use)

Description Mike Gahagan 2004-09-03 18:36:11 UTC
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 15:39:52 UTC
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 16:13:12 UTC
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 19:11:52 UTC
This bug was opened for RHEL3.  Is there any need for another bug to
be opened?

Comment 17 Dave Maley 2005-01-04 16:07:33 UTC
what's the status of getting a RHEL3 update for this?  will it make U5?

Comment 18 Havoc Pennington 2005-01-18 18:30:51 UTC
Reopening and moving to caillon for RHEL3 backport.

Comment 19 Christopher Aillon 2005-01-18 21:16:15 UTC
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 21:36:58 UTC
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 21:52:36 UTC

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