164021 - mozilla 1.1b on hpux (acrobat installed) crash when open pdf file.

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Jonathan Jiang]

Test Env: Mozilla 1.1.b on hpux11, acrobat's read 4.05
repeat steps:

1. download package 
download url = http://www.adobe.com/products/acrobat/alternate.html
filename=hpux-rs-405.tar.gz

2. install run steps 
gunzip -c hpux-rs-405.tar.gz | tar xvf -
cd HPUXRS.install
./INSTALL (will install to path /opt/Acrobat4)

3. config steps
PATH=/opt/Acrobat4/bin:$PATH
export PATH

make softlink
ln -
s /opt/Acrobat4/Browsers/hppahpux/nppdf.so /home/tst/mozilla/dist/bin/plugins/np
pdf.so

4. err result
when load a pdf file, mozilla crash and the result are
	$ ./mozilla
	md5sum not found.
	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
	/usr/lib/dld.sl: Unresolved symbol: XmProcessTraversal (code)  
from /opt/Acrobat4/Browsers/hppahpux/nppdf.so

BTW, Mozilla 1.1b(win) is fine.

rgds, Jonathan.

Comment 1

[serge (gone)]

>/usr/lib/dld.sl: Unresolved symbol: XmProcessTraversal (code)
because motif libXm cannot be found, which is strange.
Can launch stand alone acrobat?
 

Comment 2

[Jim Dunn]

hmmm my guess is that the acrobat plugin
requires mozilla to be linked against -lXm
I had a bug against this, but didn't feel it
was necessary.

Fix is simple
in modules/plugin/base/src/Makefile.in
for HP-UX
link with -lXm

Comment 3

[Jonathan Jiang]

Fixed and steps:
1) I can launch /opt/Acrobat4/bin/acroread stand alone, 
then open a pdf file successfully.
(2) I can also let netscape 4.7 on hpux works with above steps for viewing pdf.

Fixed.
(3) vi /mozilla/modules/plugin/base/src/Makefile, 
add CXXFLAGS +=-lXm
touch * ; gmake clean; gmake;
(4) relaunch,  now it works.

Thanks,

Comment 4

[Jim Dunn]

up, you don't mark it fixed until code has been
checked into the trunk that fixes the problem.

re-opening and assigning to martin

btw you should use cxxflags for adding -lXm
you should use EXTRA_DSO_LDOPTS

Comment 5

[Jim Dunn]

reassigning

Comment 6

[Martin Lawyer]

Reference:  Bug 51376

Comment 7

[Martin Lawyer]

Attachment: Copy of patch from bug 51376

Comment 8

[Martin Lawyer]

Attachment: Patch updated for OEM branch

Comment 9

[serge (gone)]

Comment on attachment 96742 [details] [diff] [review]
Patch updated for OEM branch

I would add the same 3 lines  
for MOZ_ENABLE_XLIB
r=serge

Comment 10

[Martin Lawyer]

Attachment: Patch updated with serge's suggestion

Comment 11

[Martin Lawyer]

Reassigning QA Contact.   Moving [e-mail] to CC list. 

Comment 12

[Boris Zbarsky [:bzbarsky]]

So... is this patch in need of checking in?  Has it been checked in?  What's the
state of things here?

Comment 13

[Jim Dunn]

Attachment: better patch

No it isn't fixed.
HOWEVER, if this is going to get fixed it should be fixed 
similar to bug 98892.  NOTE: I haven't tested this patch,
I am not sure of the $target_os case since all other cases
involved just $target.	Will verify tomorrow (note this
is needed on both 11 & 10.20).

Comment 14

[Matthias Versen [:Matti]]

marking NEW

Comment 15

[Jens Hatlak (:InvisibleSmiley)]

1. Bug 188941 seems to be a duplicate of this one
2. I also see this on Sparc Solaris

Comment 16

[Jim Dunn]

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

Comment 17

[Jens Hatlak (:InvisibleSmiley)]

Now confirming this on Sparc Solaris with both the 4.x and 5.x plugins.
Additional note: This worked some month ago -> regression? Didn't update for a
while in between because of another (now fixed) bug...

Comment 18

[Jim Dunn]

no, not a regression.  Chances are the solaris builds you
were getting were either based on the OEM branch or had this
patch included in them.  But the fix has never hit the trunk.
Patch needs to be updated to include solaris, reviewed and
checked in.

NOTE: also removing *fixed* from summary.  *fixed* only applies
to the 1.0 OEM branch, which is indicated via keyward fixedOEM.

Comment 19

[Roland Mainz]

The
-- snip --
/usr/lib/dld.sl: Unresolved symbol: XmProcessTraversal (code)
-- snip --
indicats that the plugin code assumes the main application is linked against the
Motif libs (Motif-1 unformtunately in the NS4.x case... ;-( ).

So a question to the Solaris users who see this bug:
Does it help to start Mozilla like this:
% (LD_PRELOAD=/usr/dt/lib/libXm.so.3 ./mozilla) # ?

Comment 20

[Jens Hatlak (:InvisibleSmiley)]

Bingo! Starting with LD_PRELOAD as described in comment #19 fixes the problem on
Solaris. Is there a way to fix that in the builds or will I have to use that var
setting from now on?

Comment 21

[Roland Mainz]

Jens Hatlak wrote:
> Bingo! Starting with LD_PRELOAD as described in comment #19 fixes the problem 
> on Solaris. Is there a way to fix that in the builds or will I have to use 
> that var setting from now on?

It may be better to contact the _plugin_vendor_ to fix their plugin code (and
maybe someone tells them that /usr/dt/lib/libXm.so.3 is the old&&buggy Motif1
lib and that Motif2 (e.g. /usr/dt/lib/libXm.so.4) should be used instead), it
seems it is simply missing a linker reference to /usr/dt/lib/libXm.so.3

Implementing that hack for Mozilla is _NOT_ recommended since it will likely
break plugins which use newer Motif libraries (like the Motif2 lib in
/usr/dt/lib/libXm.so.4).
One possible option would be to write a small piece of code which checks whether
1. any libXm.* is not being refernced (see output of /usr/bin/ldd) by the plugin
shared library (*.so)
  and
2. check whether there are any symbols in the code which starts with "Xm"
(case-sensitive)
If both [1] and [2] are "true" then /usr/dt/lib/libXm.so.3 should be loaded if
the plugin instantiation has failed previously (e.g. first we would try to load
and instantiate the plugin without the hack, and if that fails then test [1] and
[2] - and if both conditions are "true" then try the hack...).

Comment 22

[Jim Dunn]

IMHO asking the plugin vendor to fix this is silly.
(do you want me to go into why it is silly...)
THE CORRECT FIX IS TO GET THE CORRECT PATCH CHECKED IN!
This should have been taken care of a year ago but wasn't.
IBM/AIX got there fix/patch in and HP-UX/Solaris should 
follow suit.  Someone just has to own this and do it!

Comment 23

[Jim Dunn]

Attachment: HP & Solaris patch

Can people test this and let me know?!?

Comment 24

[Jens Hatlak (:InvisibleSmiley)]

This bug is open now for quite some time and this is a pity because it worked
for a long time before this became (in my eyes) a regression. However, I think
it's partly my fault because I reported the Solaris problem and then didn't
answer after the patch was posted here. The reason was that I'm not that
familiar with building Mozilla and had to wait until someone with enough
knowledge from our university could apply the patch, build and let me test. That
finally happened and here is the *result*:

1. There's no more crash (on Sparc Solaris; either Acrobat 4 or 5)
2. The Acrobat 5 plugin does nothing at all; Mozilla just stops loading.
3. The Acrobat 4 plugin outputs the following:
"Acrobat plug-in. Could not find Acrobat External Window Handler Plugin." and
nothing else happens.

The only other plugin installed is Java 1.4.2, I'm using a fresh profile and a
Forte-compiled Sparc Solaris build of Mozilla 1.5a with nothing modified but the
patch attached to this bug being applied, Calendar enabled and XPrint disabled.

While I don't know if this affects Acrobat/this bug, I should also note that I'm
unable to (let) Mozilla compile with gcc, let it be 2.9x or 3.x (for reasons not
to be discussed here).

HTH

Comment 25

[Andreas Lange]

Jens Hatlak pointed me in the direction of this bug. I think he saw the checkin
in HEAD for my patch in bug 211587 which has been verified to solve the crash
for Solaris.

I think this is slighly different from bug 98892, where AIX needs special
linking order to not crash for several plugins. This is simply about the Acrobat
plugin not beeing linked with libXm as it should. The unix plugin code already
has some tricks to handle this (quite similar to what Roland suggested in
comment 21).

I'll attach a patch shortly which is a bit more general version of my Solaris
patch with updated comment and add libXm to HPUX.

Comment 26

[Andreas Lange]

Attachment: 1_[4|5]_BRANCH patch to nsPluginsDirUnix.cpp, HPUX/Solaris

Patch against the branches, HEAD looks slightly different.

Someone with a HPUX should test this! I can only speak for the Solaris case.

Will attach patch against HEAD as soon as I recieve some response on this one.

Comment 27

[Andreas Lange]

Attachment: Branch patch again, now within defines to be less invasive

Comment 28

[Andreas Lange]

Attachment: nsPluginsDirUnix.cpp patch against trunk.

This subsumes the Solaris patch from 211587 by adding HPUX to libXm-list,
moving the LoadLibrary with PR_LD_NOW within the GTK-defines and adds an else
for non-gtk-builds so that they remain unaffected. Tested on linux and solaris.

Comment 29

[Andreas Lange]

Comment on attachment 132134 [details] [diff] [review]
nsPluginsDirUnix.cpp patch against trunk. 

Peter, could you please take a look at this one? It is almost the same you gave
r in bug 211587, except adapted for HP-UX as well.

Seems no one with HP-UX actually cared enough to try it, but it should work as
the same work-arounds as for Solaris worked...

Comment 30

[Kishan Thomas]

I will try the patch on HP-UX build with Acrobat and update the bug.

Comment 31

[Kishan Thomas]

Tested the patch on HP-UX and it works fine.

Comment 32

[Andreas Lange]

Comment on attachment 132134 [details] [diff] [review]
nsPluginsDirUnix.cpp patch against trunk. 

Seeking sr and checkin for this patch. Has r from peterlubczynski. Tested on
Linux, Solaris and HPUX (thanks Kishan!).

Comment 33

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 132134 [details] [diff] [review]
nsPluginsDirUnix.cpp patch against trunk. 

sr=bzbarsky

Comment 34

[Boris Zbarsky [:bzbarsky]]

Patch checked in.

Comment 35

[Jens Hatlak (:InvisibleSmiley)]

This has been fixed in Mozilla for some time now. Just to close the issue raised
by me in comment 24: I managed to get Acrobat 5 work by setting execution
permissions on both the plugin itself (nppdf.so) and the *.api files (chmod
o+x). I don't know if they are set by default and were only unset here at
university by our maintainers but it's clear that this can be fixed with the
steps outlined above. Enjoy!

Comment 36

[Boris Zbarsky [:bzbarsky]]

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