69167 - plugin load fails silently on library not found

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect, P1)

Description

[Adrian Robert]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-3 i686; en-US; Galeon) Gecko/20010215
BuildID:    2001021503

Mozilla will fail silently with no error message or other report if, when
attempting to load a dynamic library in the plugins directory, it is unable to
load another dynamic library required by the plugin.  This can happen, for
example, when a symbolic link is absent.  On loading the flash plugin, for
example, "libXt.so" is looked for, and if that isn't there (linking to
libXt.so.6 on a RedHat 6.2 system), the operation is aborted.

Although this is a deficiency in the system installation and not Mozilla per se,
it is a common one (my stock RedHat 6.2 system had no link for libXt.so or
libXext.so), and a simple error message could make it trivial to diagnose.  As
it stands, I spent a long time searching newsgroups before finally studying
'strace' output for a while and evantually finding the problem..

Reproducible: Always
Steps to Reproduce:
cd /usr/X11R6/lib
rm libXt.so (usually a symbolic link to libXt.so.6)
run mozilla

Actual Results:  many plugins will fail to load, with no error message

Expected Results:  Something like:

ERROR loading plugin "libflashplayer.so": required support library "libXt.so"
not found.

Comment 1

[Boris Zbarsky [:bzbarsky]]

setting status to new

Comment 2

[serge (gone)]

Attachment: this is a patch, which does some output into stderr

Comment 3

[serge (gone)]

adding myself to cc list

Comment 4

[av (gone)]

Wouldn't it be better to change

+    char errorMsg[1024] = "Cannot get error from NSPR.";

to 

+    char errorMsg[] = "Cannot get error from NSPR."; ?

Comment 5

[serge (gone)]

it would not, because PR_GetErrorText(errorMsg) does memcpy() some C string, 
with strlen()== PR_GetErrorTextLength() into its char *arg,  
so it's  reasonable to have char buffer big enough, it can hold long message.

Comment 6

[av (gone)]

Right. I overlooked that line. r=av

Comment 7

[Boris Zbarsky [:bzbarsky]]

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

Comment 8

[karnaze (gone)]

Reassigning to serge and moving to m0.9.

Comment 9

[serge (gone)]

moving to m0.9.1

Comment 10

[Peter Lubczynski]

Serge, did you ever check this in?

Comment 11

[serge (gone)]

No, I did not. TM==1.0

Comment 12

[David Hagood]

Would be nice: if on the about:plugins page, plugins that were found but not
loaded were listed, along with a reason for why not (e.g. nppdf.so - not loaded,
couldn't find foo.so)

I cannot get the Adobe Acrobat plug-in to load, even though ldd'ing the plug-in
shows no unusual library requirements (just libc6 and ld-linux.so)

Comment 13

[Peter Lubczynski]

See bug 84427 for a possible solution.

Comment 14

[cls]

Actually, the patch in 84427 wouldn't solve this problem.  See bug 74938 for
info about the acrobat problem.

Comment 15

[Xiaobin Lu]

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

Comment 16

[Stephan Jaensch]

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

Comment 17

[Stephan Jaensch]

This is a duplicate of bug 65055, which is assigned and has a better patch.

*** This bug has been marked as a duplicate of 65055 ***

Comment 18

[serge (gone)]

Stephan,
first of all, don't you think bug 65055 is special case of this one?
second, what better patch you are talking about?
and last,  would you mind to ask the owner of the bugs which already have any 
patches before you mark its as
resolve : duplicate? 
Thanks

Comment 19

[Stephan Jaensch]

Well, as far as I can see bug 65055 describes the same problem (plugins linked
against libXt.so which on some systems doesn't exist), it's just worded differently.

As for the patch: This bug has only a patch that prints out some error messages
while bug 65055 has a patch that corrects library loading in the unix plugin loader.

If I misinterpreted something or did something else wrong, then by all means
clean up the mess I made! :-)

Comment 20

[Boris Zbarsky [:bzbarsky]]

This bug is about plugin loads failing for lack of _any_ library, not just
libXt.so.  In the general case we can't actually make the plugin load; all we
can do is give an error message.

Reopening.  This patch has r=, adding "approval" keyword.

Comment 21

[Keyser Sose]

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

Comment 22

[serge (gone)]

Attachment: the second iteration, it's pretty much self explainable, I hope

Comment 23

[josh]

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

Comment 24

[av (gone)]

After closer look at the patch I just found some things I would like to see 
different or explained

In LoadExtraSharedLibs():

1. why
     sonameList = DEFAULT_EXTRA_LIBS_LIST;
     sonameList = PL_strdup(sonameList);
   rather than just
     sonameList = PL_strdup(DEFAULT_EXTRA_LIBS_LIST);

2. arrayOfLibs should be primed with nulls.

3. using 32 in while(p && numOfLibs < 32) ... I would prefer 
sizeof(arrayOfLibs)/sizeof(char *) or even better just define something like 
PLUGIN_MAX_NUMBER_OF_EXTRA_LIBS and use it instead

4. when you fill arrayOfLibs array, does the code address a situation when the 
tocken is the last character in the sonameList?

5. is there a guarantee that arrayOfLibs elements will be null-terminated? The 
comments in nsCRT.h look scary.

6. trimming off the spaces code should probably take care of tabs too

7. in this trimming code you assume that there cannot be spaces in the middle of 
the string. I just don't know how well justified this assumption is but would 
prefer not making it

To be continued...

Comment 25

[av (gone)]

8. why
     while (*(p = &sonameListToSave[PL_strlen(sonameListToSave) -1]) == ':')
       *p = 0; //delete tail ":" delimiters
   but not 
     if (*(p = &sonameListToSave[PL_strlen(sonameListToSave) -1]) == ':')
       *p = 0; //delete tail ":" delimiters

General.

10. How about taking a chance to fix bad tabbing style in this file?

Comment 26

[av (gone)]

Removing my r= from the Status line since it was for the older patch.

Comment 27

[serge (gone)]

1. try strdup("1234" "567"); and you will get compiler error;
2. why?
3. agree
4. do you mean what happen when we call LoadExtraSharedLib(0,0,1)?
5. strtok_r() is a standard function.
6. maybe
7. correct
8. yes, that looks ugly, I'm going to change it to:
for (p = &sonameListToSave[PL_strlen(sonameListToSave) - 1]; *p == ':'; p--)
*p = 0; //delete tail ":" delimiters
10.will do.

Comment 28

[av (gone)]

1. OK.
2. Paranoya. Because uninitialized pointers like to cause problems. You indeed 
count things and are not supposed to go beyond it but bugs always happen and a 
possibility for a simple check for null is a good thing to have. What is wrong 
with say 
  char *arrayOfLibs[32] = {0};?
4. I mean you will have a valid empty string listed as a library name. Not a big 
deal of course but why not to throw it out?
5. OK.

With that two items addressed or just declaring me paranoic, r=av

Comment 29

[serge (gone)]

2. sure, tough it'll slightly increase binary footprint.
4. agree

Comment 30

[serge (gone)]

Attachment: with all av's issues resolved

Comment 31

[Chris Waterson]

shaver, do you have any thoughts on this?

Comment 32

[av (gone)]

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

Comment 33

[av (gone)]

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

Comment 34

[av (gone)]

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

Comment 35

[Jeff Shultz]

If 95169 is a dupe of this bug, why did where my plug-ins working and registered
with the previous version of Mozilla that I had installed?

Comment 36

[Jeff Shultz]

Let's try that again (changed thoughts in the middle of typing). Prior to
upgrading to .93, Flash worked. Now it doesn't. The only thing that happened was
installing .93. I'm trying to clean out all of my Mozilla stuff (the previous
install appears to have hung around instead of being quietly upgraded out of
existance). 

Comment 37

[av (gone)]

Raising priority ans updating the mile stone. This bug causes flood of 
incarnations, very soon most of this bug report will be just dup notifications.

Blizzard, would you be willing to superreview?

Comment 38

[Christopher Blizzard (:blizzard)]

Using popen() is completely unacceptable to me.  Please find another method.

Comment 39

[serge (gone)]

agreed, the patch w/o popen is following

Comment 40

[serge (gone)]

Attachment: without popen()

Comment 41

[serge (gone)]

Attachment: the same as above with -u

Comment 42

[av (gone)]

Couple of dumb questions. Is it possible to have the name like libname.so.12?
And is it possible to have two names like libname.so.6 and libname.so.7?

Comment 43

[Christopher Blizzard (:blizzard)]

Woah there hoss.  This seems really over complicated.  Why don't you include the
full path to the files to load in the prefs.js file?  That would both remove a
lot of the code in this patch and remove the the hard coded paths ( yuck! )

Comment 44

[serge (gone)]

Is it possible to #ifdef in pref.js?
I mean, I have to #ifdef path to libX* for different unix flavor somehow, that's 
all I've hardcoded.

Comment 45

[serge (gone)]

to av:
well, in general the answers are yes, probably in 5+ years we would have 
libXt.so.XX... the most important thing is all extra libs are pref configurable.

Comment 46

[av (gone)]

blizzard: hardcoded paths are just default, we should have at least something if 
there is nothing in prefs. As far as I understand any path can be specified in 
prefs and will be picked up. If we want to specify the default paths in prefs 
the initial distribution then it is going to become more complex since as serge 
mentioned we will probably need separate preference keys for every kind of unix.

Comment 47

[av (gone)]

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

Comment 48

[av (gone)]

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

Comment 49

[av (gone)]

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

Comment 50

[Peter Lubczynski]

Is this going to make mozilla0.9.4 today? It still needs a super review.

Comment 51

[Peter Lubczynski]

Something like 12 dups here.....marking mostfreq

Comment 52

[Frederic Crozat]

Why libXt.so.MAJOR detecting is not done at configure level, and then used
directly when trying to dlopen the library ? This would simplify the logic at lot !

Comment 53

[serge (gone)]

the fix allows to load any libs in any order.

Comment 54

[Chris Waterson]

Sure, this looks fine to me. sr=waterson

Comment 55

[av (gone)]

Thanks, Chris! Serge would you please seek for drivers approval and get it in
ASAP so it finds its way in 0.9.4?

Comment 56

[Robert O'Callahan (:roc) (email my personal email if necessary)]

a=roc+moz on behalf of drivers

Comment 57

[serge (gone)]

checked in
new revision: 1.9; previous revision: 1.8
resolved as fixed

Comment 58

[av (gone)]

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

Comment 59

[Jason McCormick]

Possible regression??  I installed the 8-30 trunk and now plugins don't work
again.  They fail with (for example):

LoadPlugin: failed to initialize shared library
/opt/mozilla/plugins/libflashplayer.so [/opt/mozilla/plugins/libflashplayer.so:
undefined symbol: overrideShellClassRec]

The Java plug-in fails with a similar message.  Should I open a new bug on this?

Comment 60

[serge (gone)]

Jason McCormick, did you try about:plugins, what did you see?

Comment 61

[Jason McCormick]

Serge: Mozilla refuses to start until I've removed everything but the null
plug-in.  Then Mozilla displays only the default plugin.

Comment 62

[serge (gone)]

Hmm, that's strange, I've just tested  08-30-08-trunk,
my plugins dir:
-rwxr-xr-x    1 serge   18904 Jul 27 00:42 libnullplugin.so*
lrwxrwxrwx    1 serge      41 Aug 10 12:13 libflashplayer4.so ->
/home/serge/plugins/linux/libflashplayer4.so*
---
messages from console:
LoadPlugin: failed to initialize shared library
/u/serge/plugins/linux/libflashplayer4.so [undefined symbol: overrideShellClassRec]
LoadPlugin: failed to initialize shared library libXt.so [libXt.so: cannot open
shared object file: No such file or directory]
---
everything work just fine.
In your case this is the last output
/opt/mozilla/plugins/libflashplayer.so [/opt/mozilla/plugins/libflashplayer.so:
undefined symbol: overrideShellClassRec]
and mozilla hangs, am I right?

Comment 63

[serge (gone)]

Jason: could you ls -l /usr/X11R6/lib/libXt.*,
it's possible you have a wrong link for libXt.so

Comment 64

[Jason McCormick]

Serge:

libXt.a
libXt.so -> libXt.so.6.0
libXt.so.6 -> libXt.so.6.0
libXt.so.6.0
libXtst.a
libXtst.so -> libXtst.so.6.1
libXtst.so.6 -> libXtst.so.6.1
libXtst.so.6.1

This hasn't been upgraded in a long time.

Comment 65

[serge (gone)]

Joson: what is the last console message you are seeing?

Comment 66

[Jason McCormick]

Serge:

  While I was setting up to mail you the console window, Mozilla started w/
plugins.  It took about 90 seconds (1.3Ghz, 256M) to start.  Here's the console:

../run-mozilla.sh ../mozilla-bin
MOZILLA_FIVE_HOME=/opt/mozilla/plugins/..
  LD_LIBRARY_PATH=/opt/mozilla/plugins/..:/opt/mozilla/plugins/../plugins
     LIBRARY_PATH=/opt/mozilla/plugins/..:/opt/mozilla/plugins/../components
       SHLIB_PATH=/opt/mozilla/plugins/..
          LIBPATH=/opt/mozilla/plugins/..
       ADDON_PATH=/opt/mozilla/plugins/..
      MOZ_PROGRAM=../mozilla-bin
      MOZ_TOOLKIT=
        moz_debug=0
     moz_debugger=
LoadPlugin: failed to initialize shared library
/opt/mozilla/plugins/../plugins/libflashplayer.so
[/opt/mozilla/plugins/../plugins/libflashplayer.so: undefined symbol:
overrideShellClassRec]
LoadPlugin: failed to initialize shared library
/opt/mozilla/plugins/../plugins/ShockwaveFlash.class
[/opt/mozilla/plugins/../plugins/ShockwaveFlash.class: invalid ELF header]
LoadPlugin: failed to initialize shared library
/opt/mozilla/plugins/../plugins/java2 [/opt/mozilla/plugins/../plugins/java2:
cannot read file data: Is a directory]


I tried installing Java and that didn't work as it used to.  Kept telling me "A
previous installation needs to complete".  I dunno.  I hope I'm not wasting your
time w/ this but I just thing it's behaving oddly.

Comment 67

[Christopher Blizzard (:blizzard)]

I'm getting this error, too.

Comment 68

[serge (gone)]

I'm having the same problem with java installer, by some reason there is
xpicleanup process is hanging around, you have to kill -9 it.

Comment 69

[shrirang khanzode]

that is bug 89499

Comment 70

[serge (gone)]

about loading not *.so files there is a bug 97362;
about LoadPlugin: output, I do print out failure messages after first attempt to
load plugins lib,before loading extra shared libs, which is not right, it means,
for example for libflashplayer.so we always will see
LoadPlugin: failed to initialize shared library [./libflashplayer.so: undefined
symbol: overrideShellClassRec]
so, here is a simple patch which reports the problem after second load of plugin.

Comment 71

[serge (gone)]

Attachment: patch to print out failure problem after second load of plugin

Comment 72

[serge (gone)]

I'm reopening this.
av, waterson: I'm sorry for disappointment, and again could you r/sr= , please?

Comment 73

[av (gone)]

r=av

Comment 74

[Chris Waterson]

Comment on attachment 47825 [details] [diff] [review]
patch to print out failure problem after second load of plugin

sr=waterson for attachment 47825 [details] [diff] [review]

Comment 75

[Robert O'Callahan (:roc) (email my personal email if necessary)]

a=roc+moz on behalf of drivers

Comment 76

[serge (gone)]

checked in
/cvsroot/mozilla/modules/plugin/base/src/nsPluginsDirUnix.cpp,v  <-- 
nsPluginsDirUnix.cpp
new revision: 1.10; previous revision: 1.9

Comment 77

[Jason McCormick]

With build 2001090712, I'm seeing a regression on this issue.  Once again, I'm
seeing the installation of plugins causing Mozilla to simply no start with no
error message.  It stops responding after loading the Qfa.

Comment 78

[serge (gone)]

Jason, lets investigate the problem.
1. mv plugins plugins.OLD; ./mozilla
2. mkdir plugins;
ln -sf plugins.OLD/libnullplugin.so plugins/libnullplugin.so; ./mozilla
3. ln -sf plugins.OLD/libflashplayer.so plugins/libflashplayer.so, ./mozilla
4. the same for libjavaplugin_oji.so
which step causes the problem?

Comment 79

[Jason McCormick]

Hrmm... none of those make it fail.  Now it starts up.  After I moved
plugins.OLD back to plugins, everything works again....  I can't explain it.  I
started w/ a clean install of Mozilla yesterday and everything.  Sorry to waste
your time.

-- Jason

Comment 80

[shrirang khanzode]

marking verif.

Comment 81

[Peter Lubczynski]

Eeek, this is not on the mozilla 0.9.4 branch. Reopening.....

Comment 82

[serge (gone)]

mozilla/modules/plugin/base/src/nsPluginsDirUnix.cpp revision: 1.10 has 
MOZILLA_0_9_4_BRUNCH tag, so it is on the mozilla 0.9.4 branch.
Changing TM, and resolving as FIXED.

Comment 83

[shrirang khanzode]

works on branch now 0925.VERIF

Comment 84

[shrirang khanzode]

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