Closed Bug 105334 Opened 23 years ago Closed 23 years ago

solaris acrobat plugin requires motif

Categories

(Core Graveyard :: Plug-ins, defect)

Sun
Solaris
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.0

People

(Reporter: geoff, Assigned: srgchrpv)

References

Details

(Whiteboard: [ADT1])

Attachments

(2 files)

When trying to load nppdf.so: ld.so.1: ./mozilla-bin: fatal: relocation error: file /export/home/mozilla/mozilla/./plugins/nppdf.so: symbol XmProcessTraversal: referenced symbol not found Killed P.S. Yes I'm using netscape 6 to report the bug, but the bug is happening on mozilla. Netscape 6 doesn't load the plug-in either but just does a segmentation fault.
--->serge
Assignee: av → serge
Status: UNCONFIRMED → NEW
Ever confirmed: true
Geoff, could you clarify mozilla build number, please.
Sorry, I forgot the build number - it is 2001101610
My hunch is that -lXm needs to be added to the link statement. Since if I do an ldd for mozilla-bin, libXm isn't listed, nor is it listed for nppdf.so, but it is the library that is missing from the link library list. I don't know if it is missing from nppdf.so or mozilla-bin --- but somebody is looking for it!
Chris Seawood knows more about our build system.
Mozilla definitely isn't looking for it. The last bits of 3yr bitrotten unused Motif code were cvs removed from the tree last week. The adobe plugin is a 4x plugin so it was built against Motif. [root@localhost plugins]# nm nppdf.so | grep Xm 00004530 t XmProcessTraversalWannabe__FP10_WidgetRec20XmTraversalDirection It shouldn't be requiring it at runtime though. It doesn't on Linux. Solaris may be another story since it ships with Motif libs. Which package did you install nppdf.so from? Going to http://ftp.fedworld.gov/pub/irs-pdf/f1040nre.pdf works with my 0.9.5 Linux build. (cvs build is still going)
my nppdf.so came with acrobat4. I've tried to find a newer library but can't locate one. The adobe site sends me the 4.05 version even when I ask for 5.
From the solaris acrobat 4.05 plugin: sheep:~> /usr/ccs/bin/nm ~/sol-acrobat4/Browsers/sparcsolaris/nppdf.so | grep Xm [510] | 0| 0|NOTY |GLOB |0 |UNDEF |XmGetFocusWidget [473] | 0| 0|NOTY |GLOB |0 |UNDEF |XmProcessTraversal *sigh* So who wants to add the hack to attempt to load libXm.so if a plugin fails to load?
Summary: plug in load failure → solaris acrobot plugin requires motif
cc:ing Liz from Adobe
>So who wants to add the hack to attempt to load libXm.so if a plugin fails to load? it's already in (see bug 69167), just add libXm.so into prefs.js user_pref("plugin.soname.list", ...) I did not get any relocation errors from ld.so on solaris 5.6 using mozilla 2001101510 build, but I got "Acrobat plug-in. An internal error has occurred":( Debugging...
Oh cool. I didn't know about that feature. That should probably be put in the relnotes (if it isn't already).
Unfortunately, there is a bad habit among developers -- not to propagate a message about introducing new hidden preferences. Me included. I have two such prefs of my own nobody knows about. Everything should be documented somewhere. Period. I think the best (and easiest) way for the engineer to get of the responsibility is just to file a bug against Evangelism or whatever component handles the docs). Let's not neglect this.
Wonderful, I've just added libXm into prefs.js and the pdf plugin works fine. Many thanks to all of you.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Call me stupid, but how do I change this on a system-wide basis? The only prefs.js I can find is in my personal .mozilla directory.
try <mozilla_install_dir>/defaults/pref/unix.js
I don't ahve a solaris box but am marking verif based on Geoff's comment.
Status: RESOLVED → VERIFIED
I have a fresh Solaris moz 0.9.6 (build 2001112114 - downloaded a couple of weeks ago) that has a default/prefs/unix.js file without this line in it. Also, when I did add a line for plugin.soname.list to have "libXm.so" (also tried /usr/lib/libXm.so), it didn't help - Mozilla still bombed out with the missing symbol message. The only thing that helped was forcing ld.so.1 to preload the motif library using the LD_PRELOAD=/usr/lib/libXm.so environment variable - now the acrobat plugin finds the missing symbol (and Motif throws out lots of ugly "no type converter for pixmap" messages), and displays the document properly.
1. The entry in the site-wide or the user prefs file works to force libXm.so to load, thus fixing part of the problem where Acrobat is linked to libXm.so. For the user file in the home directory, use the user_pref(...), but in the site-wide file use the pref(...) command. This resolves the previous poster's comment that this doesn't work. Tested on Solaris 2.6 and 2.8 with Mozilla 0.9.7 ([Mozilla] Mozilla 0.9.7+ Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:0.9.7+) Gecko/20011221) pref("plugin.soname.list", "libXm.so") -or- user_pref("plugin.soname.list", "libXm.so") 2. Problems with Acrobat 4.0.5 plugin on Solaris still exist. Testing with the preference entry that forces libXm.so to load now gets Acrobat to start, but the following problems now appear **** On Solaris 2.6 it causes a seg-fault as the Acrobat splash-screen appears. There are also some messages printed to the terminal: 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 Segmentation Fault [2] Exit 11 And here is the stack-traceback from gdb 5.0: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 4)] 0xfb8d9860 in ?? () (gdb) where #0 0xfb8d9860 in ?? () #1 0xfb90ea74 in ?? () #2 0xfbaa6904 in ?? () #3 0xfbaa6dfc in ?? () #4 0xfbaa7d60 in ?? () #5 0xfbaa9094 in ?? () #6 0xfd6d5760 in ns4xPluginInstance::SetWindow () from /tools/local/mozilla/components/libgkplugin.so #7 0xfd6de288 in nsPluginHostImpl::InstantiateFullPagePlugin () from /tools/local/mozilla/components/libgkplugin.so #8 0xfd6e8778 in PluginViewerImpl::CreatePlugin () from /tools/local/mozilla/components/libgkplugin.so #9 0xfd6e856c in PluginViewerImpl::StartLoad () from /tools/local/mozilla/components/libgkplugin.so #10 0xfd6e9450 in PluginListener::OnStartRequest () from /tools/local/mozilla/components/libgkplugin.so #11 0xfdbce868 in nsDocumentOpenInfo::OnStartRequest () from /tools/local/mozilla/components/liburiloader.so #12 0xfdca7040 in nsHttpChannel::ProcessNormal () from /tools/local/mozilla/components/libnecko.so #13 0xfdca6ed8 in nsHttpChannel::ProcessResponse () from /tools/local/mozilla/components/libnecko.so #14 0xfdcad66c in nsHttpChannel::OnStartRequest () from /tools/local/mozilla/components/libnecko.so #15 0xfdccdedc in ?? () from /tools/local/mozilla/components/libnecko.so #16 0xfdc63d14 in nsARequestObserverEvent::HandlePLEvent () from /tools/local/mozilla/components/libnecko.so #17 0xff132464 in PL_HandleEvent () from /usr/local/mozilla/libxpcom.so #18 0xff132394 in PL_ProcessPendingEvents () from /usr/local/mozilla/libxpcom.so #19 0xff13342c in nsEventQueueImpl::ProcessPendingEvents () from /usr/local/mozilla/libxpcom.so #20 0xfd46f584 in nsAppShell::SetDispatchListener () from /tools/local/mozilla/components/libwidget_gtk.so #21 0xfd46f238 in keysym2ucs () from /tools/local/mozilla/components/libwidget_gtk.so #22 0xfedf6020 in g_io_unix_dispatch (source_data=0x131040, current_time=0xffbeef38, user_data=0x1caa00) at giounix.c:135 #23 0xfedf7cfc in g_main_dispatch (dispatch_time=0xffbeef38) at gmain.c:656 #24 0xfedf8598 in g_main_iterate (block=-18752156, dispatch=1) at gmain.c:877 #25 0xfedf87ac in g_main_run (loop=0x1caa10) at gmain.c:935 #26 0xfef40080 in gtk_main () at gtkmain.c:524 #27 0xfd46fb20 in nsAppShell::Run () from /tools/local/mozilla/components/libwidget_gtk.so #28 0xfc84b5f0 in nsAppShellService::Run () from /tools/local/mozilla/components/libnsappshell.so #29 0x18acc in _start () #30 0x19584 in main () *** On Solaris 2.8, it causes an X-windows error AND there is the missing symbol.Acrobat starts and its splash screen disappear. Then the Mozilla window starts to paint in, but then the error appears and Mozilla crashes. Also, messages printed to terminal: 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 ld.so.1: /usr/local/mozilla/mozilla-bin: fatal: relocation error: file /tools/local/mozilla/plugins/nppdf.so: symbol CreateQueue: referenced symbol not found Killed X Error of failed request: BadDrawable (invalid Pixmap or Window parameter) Major opcode of failed request: 70 (X_PolyFillRectangle) Resource id in failed request: 0x5c001a1 Serial number of failed request: 2284 Current serial number in output stream: 2297 I hope this info is useful
Thank you Robert, your investigation is very helpful
Hi, all, I tested the 4.0.5 plugin on my Solaris 9 ( Ultra Sparc ). 1) Defaultly, the Browser crash when loading pdf file. 2) After I add the libXm.so (motif 2.1) in pref.js, the browser will not crash, instead show a blank page with BLACK background. 3) If I change libXm.so to libXm12.so (motif 1.2) in pref.js, the browser will crash as Robert Said( Seg Fault). Idea & Questions: 1) I think the crash on Solaris 6 etc. is caused by the motif version. Which means that the 4.05 plugin is unsable on Solaris 6. 2) I don't know why it shows black page on Solaris 9, is it related to the following warnings? 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 3) Since this bug has not been resolved, is it possible to reopen it?
Hi, Sorry for some confusions in my last comments. I goto http://ftp.fedworld.gov/pub/irs-pdf/f1040nre.pdf the file is displayed correctly with motif 2.1. And no Black background. So there should be something wrong with my own Website.
Re-opening because Adobe pdf plugin still does not work by default. Shouldn't the pref line have been added to mozilla/defaults/pref/unix.js before this was closed so that the plugin would work by default? Either way, even with the pref set, the plugin still dumps core for me with build 2002013122 on Sparc Solaris 7. I'l attach the back trace which is very similar to Robert Milkovits's trace for Solaris 2.6 in comment 18, except the "??" for the first several lines are filled in. Also, issues Solaris 8 that Robert Milkovits mentions seems to be identical to the Linux issues in bug 122783. So maybe the Solaris 8 issues should be dealt with there and the remaining Solaris 2.6 and 7 issues as well as the pref issue here?
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Jim Crumley, please open a new bug on crash with the stack trace you attached here, which is clear pointing to #0 0xfd0e89a0 in _XmGetFocusData() from /usr/lib/libXm.so #1 0xfd11d060 in XmProcessTraversal() from /usr/lib/libXm.so #2 0xfc7c662c in GrabKeyEvents()from /net/belka/d2/crumley/moz2/plugins/nppdf.so motif call, it means libXm.so is already loaded, but this bug is about how mozilla loads libXm.so. Thanks.
Ok, Solaris 7 crashing behavior for Adobe pdf plugin opened as bug 123585.
Attached patch nsPluginsDirUnix.cpp.diff (deleted) — Splinter Review
Please review if this can do some work.
actually I see no diffs between hardcoded "libXm.so" or pref("plugin.soname.list", "libXm.so") or user_pref("plugin.soname.list", "libXm.so") Am I wrong?
The "problem" is that loading Motif plugins doesn't work "out-of-the-box". Since the pref is hidden (ie, no GUI), most users aren't going to know how to enable the loading of libXm.so . What about hpux, irix and other OSes that ship with a dynamic Motif lib? We should probably make loading Xm the default and drop it from the list for certain exceptions, like Linux.
Hi, Serge, I think you should also add the libXt.so and libXext.so
Thanks Jim, my comment #27 is just an example. >What about hpux, irix and other OSes that ship with a dynamic Motif lib? We >should probably make loading Xm the default and drop it from the list for >certain exceptions, like Linux. I agree, but as I recall the order of loading Xt/Xm libs could be important, see bug 51189, that why I do not like to hardcode this stuff, maybe it worth to add default_unix_flavor_specific.js file into http://lxr.mozilla.org/mozilla/source/modules/libpref/src/nsPrefService.cpp#520 specialFiles[] list and set "plugin.soname.list" as http://lxr.mozilla.org/mozilla/source/modules/libpref/src/unix/openvms.js#58 does.
Summary: solaris acrobot plugin requires motif → solaris acrobat plugin requires motif
Target Milestone: --- → mozilla1.0
Keywords: nsbeta1+
Hi, Serge, I am confused about the .so loading order. Pls take a look at my patch. http://bugzilla.mozilla.org/attachment.cgi?id=68265&action=view You can see there is a default loading order where libXt will always be loaded firstly. Since this bug is serious on Solaris, would you pls comment on the patch?
Comment on attachment 68265 [details] [diff] [review] nsPluginsDirUnix.cpp.diff no doubt it'll work for acrobat plugin on solaris, r=serge
Attachment #68265 - Flags: review+
*** Bug 131263 has been marked as a duplicate of this bug. ***
blizzard, could you sr= for this, please?
Attachment #68265 - Flags: superreview+
Comment on attachment 68265 [details] [diff] [review] nsPluginsDirUnix.cpp.diff sr=blizzard Chris Seawood has a point, though, what about other unixes? This is a fine stop gap measure for now but if we run into this again, we should generalize this somewhat and start talking about some per-unix prefs or something.
Thanks, I vote for per-unix pref, something like we have for openvms.js
in the trunk mozilla/modules/plugin/base/src/nsPluginsDirUnix.cpp new revision: 1.24; previous revision: 1.23
adding ADT1 to status whiteboard as per discussion with beppe since this is a crash.
Whiteboard: [ADT1]
Serge -- shouldn't this be marked as fixed?
resolved as fixed
Status: REOPENED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
I sent an email to Jim Song to check/mark this verif since I do not have solaris. However, it bounced back with 'user unknown' message.can anyone verify this? Thx !
Verified on 2002041322.
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: