Closed Bug 105334 Opened 23 years ago Closed 22 years ago

solaris acrobat plugin requires motif

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Platform:
Sun
Solaris
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.0

People

(Reporter: geoff, Assigned: srgchrpv)

References

Details

(Whiteboard: [ADT1])

Attachments

(2 files)

backtrace and gdb from Solaris 2.7 Adobe pdf plugin crash
5.34 KB, text/plain
Details
nsPluginsDirUnix.cpp.diff
1.00 KB, patch
srgchrpv
: review+
blizzard
: superreview+
Details | Diff | Splinter Review 
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.
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 ago → 22 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: