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 libXm.so 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: ld.so.1: /sw/mozilla-1.4/mozilla-bin: fatal: relocation error: file /sw/adobe/AcroRead_5.0.6/Browsers/sparcsolaris/nppdf.so: symbol XmProcessTraversal: referenced symbol not found Killed 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 libXm.so so it should work. Setting LD_PRELOAD=/usr/lib/libXm.so 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 mozilla/modules/plugin/base/src/nsPluginsDirUnix.cpp: 308 pLibrary = outLibrary = PR_LoadLibraryWithFlags(libSpec, 0); 309 310 #if defined(MOZ_WIDGET_GTK) || defined(MOZ_WIDGET_GTK2) 311 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 libXm.so) 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 libXm.so, 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.

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

Ah, PR_LD_NOW is simply an argument to dlopen(): RTLD_NOW 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.

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

Comment on attachment 127000 [details] [diff] [review] Try to load plugins directly, not lazy should we do this for all platforms? r=peterl

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 144 #define DEFAULT_EXTRA_LIBS_LIST "libXt" LOCAL_PLUGIN_DLL_SUFFIX ":libXext" LOCAL_PLUGIN_DLL_SUFFIX ":libXm" LOCAL_PLUGIN_DLL_SUFFIX 145 #else 146 #define DEFAULT_EXTRA_LIBS_LIST "libXt" LOCAL_PLUGIN_DLL_SUFFIX ":libXext" LOCAL_PLUGIN_DLL_SUFFIX 147 #endif

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

After blizzard's sr, could you please check this in Peter? I don't have cvs access...

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.

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.

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 nppdf.so 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, folks.

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

->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.

.

Agh! Misled by last comments - I didn't read previous where patch was checked in. I'm sorry for the SPAM.

.

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.

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

An additional approach is to link mozilla-bin binary with libXm.so 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 libXm.so and the plugin load problem goes away.