Last Comment Bug 198954 - Acrobat Plugin uses 100% CPU on GTK2 Builds
: Acrobat Plugin uses 100% CPU on GTK2 Builds
: relnote
Product: Core
Classification: Components
Component: Plug-ins (show other bugs)
: Trunk
: x86 Linux
-- normal with 23 votes (vote)
: ---
Assigned To: Peter Lubczynski
: bmartin
: Benjamin Smedberg [:bsmedberg]
: 201211 233924 239414 253868 (view as bug list)
Depends on:
Blocks: gtk2 198230
  Show dependency treegraph
Reported: 2003-03-24 06:48 PST by Mikael Nilsson
Modified: 2006-03-12 17:09 PST (History)
30 users (show)
asa: blocking1.7-
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image Mikael Nilsson 2003-03-24 06:48:49 PST
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:

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.
Comment 1 User image mjs 2003-03-27 10:57:31 PST
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 Red Hat 8.0

Same for me with the 5.06 plugin RPM.
Comment 2 User image mjs 2003-06-13 12:55:52 PDT
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.
Comment 3 User image Bill Wallace 2003-07-03 05:41:18 PDT
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?
Comment 4 User image mjs 2003-07-09 13:38:21 PDT
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.
Comment 5 User image thierry scalais 2003-09-20 11:00:33 PDT
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"
Comment 6 User image thierry scalais 2003-10-16 13:56:28 PDT
I deleted the plugin (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.
Comment 7 User image mjs 2003-10-16 17:03:08 PDT
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.
Comment 8 User image Nathan Bryant 2003-10-23 14:17:46 PDT
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.
Comment 9 User image Nathan Bryant 2003-10-23 14:21:35 PDT
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.
Comment 10 User image mjs 2003-10-23 14:26:29 PDT
Just as another data point, the 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  It would be interesting to know if it happens on the
(full) latest Severn test release.
Comment 11 User image Nathan Bryant 2003-10-23 16:51:00 PDT
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
Comment 12 User image Nathan Bryant 2003-10-29 07:29:49 PST
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.
Comment 13 User image Nathan Bryant 2003-10-29 07:42:55 PST
Bill's problem stopped happening after upgrading Mozilla and Acrobat.
Comment 14 User image David Grant 2003-11-06 15:31:14 PST
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?
Comment 15 User image Nathan Bryant 2003-11-07 07:19:41 PST
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
Comment 16 User image Robert Parenton 2004-01-13 14:40:41 PST
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.
Comment 17 User image Robert Parenton 2004-01-13 15:05:54 PST
-> 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.
Comment 18 User image Scott Baker 2004-01-13 15:07:17 PST
I concur with #17.  Sounds like normal behavior for PDF files.  They simply
require a good chunk of CPU to render. Especially complex ones.  
Comment 19 User image Nathan Bryant 2004-01-13 19:59:57 PST
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

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 
Comment 20 User image Robert Parenton 2004-01-13 20:55:22 PST
Reopening and updating summary to more accurately reflect the problem
Comment 21 User image Robert Parenton 2004-01-13 21:03:54 PST
CC'ing Christopher Blizzard as it involves GTK2
Comment 22 User image Nathan Bryant 2004-01-14 21:00:18 PST
reproduced this on tonight's mainline (vanilla--no Fedora specific patches)

My system is fully up2date Fedora 1 and has these libraries:

Mozilla is:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7a) Gecko/20040114


Build platform

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
Comment 23 User image Josko Plazonic 2004-01-19 20:02:49 PST
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.
Comment 24 User image Josko Plazonic 2004-01-21 11:47:16 PST
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.
Comment 25 User image Matthew Walburn 2004-01-30 12:12:47 PST
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

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

Comment 26 User image Prognathous 2004-02-12 03:57:52 PST
*** Bug 233924 has been marked as a duplicate of this bug. ***
Comment 27 User image Anthony Lanni 2004-02-13 16:46:51 PST
        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).  

Comment 28 User image mjs 2004-02-13 17:07:25 PST
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-  Anything else about versions of things I can tell you?
Comment 29 User image Pat Suwalski 2004-02-22 16:27:00 PST
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!).
Comment 30 User image mjs 2004-03-12 15:46:43 PST
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
Comment 31 User image mjs 2004-03-17 18:04:12 PST
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 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.
Comment 32 User image Johannes Rohr 2004-04-12 03:19:41 PDT
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. 
Comment 33 User image Josh D S Davis 2004-05-02 12:15:17 PDT
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

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="">198954</a><BR>
<a href="">219987</a><BR>

Comment 34 User image Pat Suwalski 2004-05-02 12:27:09 PDT
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.
Comment 35 User image Josh D S Davis 2004-05-02 13:20:05 PDT
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.
Comment 36 User image Brian Long 2004-06-18 10:16:26 PDT
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

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 
Comment 37 User image Fareed Rizkalla 2004-07-13 03:41:02 PDT
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.
Comment 38 User image Brian Long 2004-07-13 04:09:11 PDT
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%.
Comment 39 User image David Grant 2004-07-13 07:42:37 PDT
Brian, I'm not sure if he was referring to network bandwidth or some other kind
of bandwidth...
Comment 40 User image Robert Parenton 2004-07-13 10:54:46 PDT
It has nothing to do with any sort of bandwidth.  It is a specific bug in the
GTK2 code dealing with plugins.
Comment 41 User image Mikko Huhtala 2004-08-10 05:11:59 PDT
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.
Comment 42 User image Pat Suwalski 2004-08-10 09:07:27 PDT
Is this new binary still linked against GTK?
Comment 43 User image Nathan Bryant 2004-08-10 09:14:07 PDT
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 44 User image Robert Parenton 2004-08-10 15:44:59 PDT
Comment #41, the reason your build didn't exhibit this problem was because you
did not make a GTK2 build.
Comment 45 User image Asun 2004-09-03 16:48:45 PDT
Bug confirmed to still happen on Fedora Core 2. Mozilla version:
Acroread version:

Yes, mozilla is gtk2 enabled build.
Comment 46 User image Christopher Blizzard (:blizzard) 2004-09-10 11:02:57 PDT
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.
Comment 47 User image Christopher Blizzard (:blizzard) 2004-09-13 08:04:56 PDT
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

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.
Comment 48 User image Pat Suwalski 2004-09-13 09:30:10 PDT
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.
Comment 49 User image Brian Long 2004-09-13 09:58:54 PDT
Why not log a feature request?
Comment 50 User image David Grant 2004-09-13 11:17:28 PDT

everyone make a feature request and maybe they will listen.
Comment 51 User image Peter Kovář 2004-09-18 01:27:41 PDT
Another possible solution would be Xpdf as Mozilla
plug-in. Comments anyone?
Comment 52 User image Asun 2004-09-18 02:14:42 PDT
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?
Comment 53 User image Jeff Epler 2004-09-24 09:05:31 PDT
Also exists on Fedora Core 2 in both Mozilla and Firefox.
Mozilla and firefox are both gtk+2 builds in FC2.
Comment 54 User image alex jacobson 2004-10-05 05:43:50 PDT
(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.
Comment 55 User image mozilla3eran 2004-10-26 18:37:19 PDT
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 (""), the risk of regressions is limited.
Comment 56 User image Joshua Jensen 2004-11-11 08:17:52 PST
I've heard that Adobe's upcoming Acrobat 7 plug in targets a fix for this
Comment 57 User image Johannes Rohr 2004-11-11 11:25:50 PST
Any details on where you heard about this and when the release is scheduled?
Comment 58 User image Johannes Rohr 2004-11-11 11:32:20 PST
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.
Comment 59 User image Frederic Bezies 2004-11-23 11:34:01 PST
*** Bug 253868 has been marked as a duplicate of this bug. ***
Comment 60 User image Christopher Blizzard (:blizzard) 2004-12-15 07:12:49 PST
You will note that if you go and download the adobe reader:

That the current version is now 5.0.10.  This version fixes the 100% CPU problem.
Comment 61 User image Michael Thome 2004-12-15 07:19:45 PST
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.
Comment 62 User image Patrick 2005-01-27 15:19:43 PST
*** Bug 239414 has been marked as a duplicate of this bug. ***
Comment 63 User image Christopher Blizzard (:blizzard) 2005-02-03 09:06:13 PST
*** Bug 246560 has been marked as a duplicate of this bug. ***
Comment 64 User image Andrew Schultz 2005-04-03 14:12:58 PDT
*** Bug 201211 has been marked as a duplicate of this bug. ***
Comment 65 User image Brian Nitz 2005-04-28 06:54:01 PDT
(In reply to comment #60)
> You will note that if you go and download the adobe reader:
> 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.  
Comment 66 User image Pat Suwalski 2005-04-28 09:31:20 PDT
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.

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