Acrobat plugin crashes on Solaris in Moz 1.4, not loaded

RESOLVED FIXED in mozilla1.6alpha



15 years ago
15 years ago


(Reporter: Andreas Lange, Assigned: Peter Lubczynski)



Firefox Tracking Flags

(Not tracked)



(2 attachments)



15 years ago
User-Agent:       Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030701
Build Identifier: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030701

The Solaris acrobat plugin needs to be loaded before it starts,
otherwise it crashes and kills mozilla as well. bug 105334 is regarding exactly
this, and it contains a patch that was verified to solve the problem. I think it
worked after that, but I guess some recent changes elsewhere as turned this into
an issue again.

Reproducible: Always

Steps to Reproduce:
1. Freshly compiled Mozilla from 1.4 source release
2. Open a PDF

Actual Results: /sw/mozilla-1.4/mozilla-bin: fatal: relocation error: file
/sw/adobe/AcroRead_5.0.6/Browsers/sparcsolaris/ symbol
XmProcessTraversal: referenced symbol not found

Also tested with 4.05 with the same result. This is on Solaris 2.8 and 2.9.

Expected Results:  
After bug 105334, the plug-ins code contains Solaris-specific code to pull in
among others so it should work. Setting LD_PRELOAD=/usr/lib/
when starting Mozilla makes it work and also proves that it is exactly this that
is the problem.

I think the most relevant source here is in

308     pLibrary = outLibrary = PR_LoadLibraryWithFlags(libSpec, 0);
310 #if defined(MOZ_WIDGET_GTK) || defined(MOZ_WIDGET_GTK2)
312     ///////////////////////////////////////////////////////////
313     // Normally, Mozilla isn't linked against libXt and libXext
314     // since it's a Gtk/Gdk application.  On the other hand,
315     // legacy plug-ins expect the libXt and libXext symbols
316     // to already exist in the global name space.  This plug-in
317     // wrapper is linked against libXt and libXext, but since
318     // we never call on any of these libraries, plug-ins still
319     // fail to resolve Xt symbols when trying to do a dlopen
320     // at runtime.  Explicitly opening Xt/Xext into the global
321     // namespace before attempting to load the plug-in seems to
322     // work fine.
323     if (!pLibrary) {
324         LoadExtraSharedLibs();
325         // try reload plugin ones more
326         pLibrary = outLibrary = PR_LoadLibraryWithFlags(libSpec, 0);
327         if (!pLibrary)
328             DisplayPR_LoadLibraryErrorMessage(libSpec.value.pathname);
329     }

I've played around with debug-printouts for a while, and discovered that the
first call to PR_LoadLibraryWithFlags() actually succeds for the acrobat plugin,
and thus the call to LoadExtraSharedLibs() (which pulls in never
occurs. After a few seconds the plugin reaches the fatal XmProcessTraversal
symbol, and everything dies.

If changing line 308 to "pLibrary = NULL;", LoadExtraSharedLibs() runs, loads, and the plugin then is launched successfully from line 326.

The second argument to PR_LoadLibraryWithFlags() controls the loading strategy,
and the default value if passed a zero is PR_LD_LAZY. I haven't really dug
through all the code here so I'm guessing a bit, but since the first call
actually returned true but the plugin crashes I thought it returned a bit too
early. Changing the 0 at line 308 to PR_LD_NOW made the whole thing work as
supposed - other plugins like flash and java works at the first try while
Acrobat fails, requires a call to LoadExtraSharedLibs(), and then runs fine.

Comment 1

15 years ago
Created attachment 127000 [details] [diff] [review]
Try to load plugins directly, not lazy

I hope someone with good knowledge about library-loading in Mozilla can check
this to tell if it is a good solution or not...


15 years ago
OS: SunOS → Solaris

Comment 2

15 years ago
Ah, PR_LD_NOW is simply an argument to dlopen():

           All  necessary  relocations  are  performed  when  the
           object  is  first loaded. This may waste some process-
           ing, if relocations are performed for lazy  references
           that  are  never used. This behavior can be useful for
           applications that need to know as soon as an object is
           loaded  that  all  symbols referenced during execution
           will be available.

It might waste a few CPU cycles, but on the other hand - if the code is supposed
to check if all symbols are available and otherwise load some more libraries,
isn't RTLD_NOW necessary to really do this?

The call at line 326 should probably be changed too, it is a rare code path anyway. 

If this seems to be too much of a performance penalty for other unix platforms,
it could always be ifdef'ed SOLARIS since the loading of libXm already is so.


Comment 3

15 years ago
Created attachment 130710 [details] [diff] [review]
Alternative patch; same code but #ifdef SOLARIS, added comment

Comment 4

15 years ago
Verified that the crash still occurs with 1.5b (source). The patch still fixes
it. Added alternative patch with the code-change limited to Solaris, since it
only seems to affect libXm and that only is required on Solaris (ifdef for that
earlier in the same file).

Roland: do you have any comments?

Our config for the build looks like this:
ac_add_options --with-x
ac_add_options --enable-default-toolkit=gtk
ac_add_options --enable-toolkit-gtk
ac_add_options --disable-toolkit-xlib
ac_add_options --disable-toolkit-qt
ac_add_options --enable-crypto
ac_add_options --enable-jsd
ac_add_options --enable-xinerama
ac_add_options --enable-js-ultrasparc
ac_add_options --disable-debug
ac_add_options --enable-optimize=-O2
ac_add_options --disable-tests
ac_add_options --enable-strip
ac_add_options --disable-glibtest
ac_add_options --enable-xterm-updates
ac_add_options --enable-calendar
ac_add_options --enable-x11-shm



15 years ago
Ever confirmed: true

Comment 5

15 years ago
Comment on attachment 127000 [details] [diff] [review]
Try to load plugins directly, not lazy

should we do this for all platforms?

Attachment #127000 - Flags: review+

Comment 6

15 years ago
I don't know. Time to pull in some more people who knows, perhaps?

On one hand, if the code is supposed to check if all symbols are available and
otherwise load some more libraries, isn't RTLD_NOW necessary to really do this
(on any platform)?

On the other hand, it obviously works for almost everyone right now. And I've
only seen this with the Solaris-specific libXm, not libXt or libXext which also
are checked on the other unixes. That's why I added the other patch - if the
problem is only libXm-related (Solaris only), keep the solution Solaris only...

This is the list of libs for LoadExtraSharedLibs() in nsPluginsDirUnix.cpp:
143 #ifdef SOLARIS
145 #else
147 #endif


15 years ago
Attachment #130710 - Flags: review?(peterlubczynski-bugs)

Comment 7

15 years ago
Comment on attachment 130710 [details] [diff] [review]
Alternative patch; same code but #ifdef SOLARIS, added comment

Attachment #130710 - Flags: review?(peterlubczynski-bugs) → review+


15 years ago
Attachment #130710 - Flags: superreview?(blizzard)
Attachment #130710 - Flags: superreview?(blizzard) → superreview+

Comment 8

15 years ago
After blizzard's sr, could you please check this in Peter? I don't have cvs

Comment 9

15 years ago
sure, I've just checked it into the trunk for 1.6a, marking FIXED

Please nominate for 1.4/1.5 if you feel this is needed.
Last Resolved: 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.6alpha
This looks exactly like Bug 164021, but that one is about hpux as well. And it
doesn't WFM, same problems as mentioned in comment 24 of Bug 164021. I'd be glad
to help finding out why that is but I don't know what to do.

Comment 11

15 years ago
It sure does. Might be that the generic solution is better after all. I'll have
a look at 164021.
My last comment seemed to be a little confusing. What I was trying to say is
that the other bug is about hpux as well but that it doesn't WFM on Solaris.
Meanwhile I managed to get Acrobat 4 working by symlinking to the
plugins dir and putting the path to acroread (the version 4 binary) at the start
of $PATH - that way ewh.api, the Acrobat Window Handler plugin, is automagically
found. However, I'm still trying to get Acrobat 5 working the same way. Later,

Comment 13

15 years ago
According to comment 12, the resolution didn't have anything to do with fixing
something broken in Mozilla, but involved a different solution.

Comment 14

15 years ago
->WORKSFORME as per comments.  If this really is a *Mozilla* bug that should be
corrected, rather than just worked around, then it can be reopened.
Resolution: FIXED → ---

Comment 15

15 years ago
Last Resolved: 15 years ago15 years ago
Resolution: --- → WORKSFORME

Comment 16

15 years ago
Agh!  Misled by last comments - I didn't read previous where patch was checked
in.  I'm sorry for the SPAM.
Resolution: WORKSFORME → ---

Comment 17

15 years ago
Last Resolved: 15 years ago15 years ago
Resolution: --- → FIXED
Using a 2003-09-21 nightly I can now confirm this is really fixed. As I already
said Acrobat 4 works if you have acroread in you $PATH. Acrobat 5 also starts (I
can see its splash screen if that option is activated) but doesn't display
anything here. Anyway, this is another issue and likely a configuration problem
on my side. This bug is fixed since Mozilla doesn't crash anymore and invokes
Acrobat correctly. If anyone finds out why Acrobat 5 doesn't display anything in
some cases (like mine) I'd be glad to hear from you.

Comment 19

15 years ago
*** Bug 230530 has been marked as a duplicate of this bug. ***

Comment 20

15 years ago
An additional approach is to link mozilla-bin binary with on 
Solaris.  I am not familiar (yet) with the architectural and design
goals of the mozilla source, but rather than mangling the source
code and adding yet another #ifdef, one can simply explicitly link
with and the plugin load problem goes away.  
You need to log in before you can comment on or make changes to this bug.