Closed
Bug 69167
Opened 24 years ago
Closed 23 years ago
plugin load fails silently on library not found
Categories
(Core Graveyard :: Plug-ins, defect, P1)
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla0.9.4
People
(Reporter: arobert, Assigned: srgchrpv)
References
Details
(Whiteboard: r=av, sr=waterson, a=roc+moz)
Attachments
(6 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
waterson
:
superreview+
|
Details | Diff | Splinter Review |
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.
Assignee | ||
Comment 2•24 years ago
|
||
Assignee | ||
Comment 3•24 years ago
|
||
adding myself to cc list
Wouldn't it be better to change
+ char errorMsg[1024] = "Cannot get error from NSPR.";
to
+ char errorMsg[] = "Cannot get error from NSPR."; ?
Assignee | ||
Comment 5•24 years ago
|
||
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 8•24 years ago
|
||
Reassigning to serge and moving to m0.9.
Assignee: av → serge
Target Milestone: --- → mozilla0.9
Assignee | ||
Updated•23 years ago
|
Target Milestone: mozilla0.9.1 → mozilla1.0
Comment 10•23 years ago
|
||
Serge, did you ever check this in?
Assignee | ||
Comment 11•23 years ago
|
||
No, I did not. TM==1.0
Comment 12•23 years ago
|
||
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•23 years ago
|
||
See bug 84427 for a possible solution.
Comment 14•23 years ago
|
||
Actually, the patch in 84427 wouldn't solve this problem. See bug 74938 for
info about the acrobat problem.
Comment 15•23 years ago
|
||
*** Bug 85049 has been marked as a duplicate of this bug. ***
Comment 16•23 years ago
|
||
*** Bug 80459 has been marked as a duplicate of this bug. ***
Comment 17•23 years ago
|
||
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 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Assignee | ||
Comment 18•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
*** Bug 88481 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 22•23 years ago
|
||
Comment 23•23 years ago
|
||
*** Bug 91302 has been marked as a duplicate of this bug. ***
Comment 24•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
Removing my r= from the Status line since it was for the older patch.
Whiteboard: r=av, sr=? → r=?, sr=?
Assignee | ||
Comment 27•23 years ago
|
||
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.
Whiteboard: r=?, sr=? → r=av, sr=?
Comment 28•23 years ago
|
||
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
Assignee | ||
Comment 29•23 years ago
|
||
2. sure, tough it'll slightly increase binary footprint.
4. agree
Assignee | ||
Comment 30•23 years ago
|
||
Comment 31•23 years ago
|
||
shaver, do you have any thoughts on this?
Comment 32•23 years ago
|
||
*** Bug 79124 has been marked as a duplicate of this bug. ***
Comment 33•23 years ago
|
||
*** Bug 95096 has been marked as a duplicate of this bug. ***
Comment 34•23 years ago
|
||
*** Bug 95169 has been marked as a duplicate of this bug. ***
Comment 35•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
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?
Priority: -- → P1
Target Milestone: mozilla1.0 → mozilla0.9.4
Comment 38•23 years ago
|
||
Using popen() is completely unacceptable to me. Please find another method.
Assignee | ||
Comment 39•23 years ago
|
||
agreed, the patch w/o popen is following
Assignee | ||
Comment 40•23 years ago
|
||
Assignee | ||
Comment 41•23 years ago
|
||
Comment 42•23 years ago
|
||
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•23 years ago
|
||
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! )
Assignee | ||
Comment 44•23 years ago
|
||
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.
Assignee | ||
Comment 45•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
*** Bug 96004 has been marked as a duplicate of this bug. ***
Comment 48•23 years ago
|
||
*** Bug 95901 has been marked as a duplicate of this bug. ***
Comment 49•23 years ago
|
||
*** Bug 65055 has been marked as a duplicate of this bug. ***
Comment 50•23 years ago
|
||
Is this going to make mozilla0.9.4 today? It still needs a super review.
Comment 51•23 years ago
|
||
Something like 12 dups here.....marking mostfreq
Comment 52•23 years ago
|
||
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 !
Assignee | ||
Comment 53•23 years ago
|
||
the fix allows to load any libs in any order.
Comment 54•23 years ago
|
||
Sure, this looks fine to me. sr=waterson
Comment 55•23 years ago
|
||
Thanks, Chris! Serge would you please seek for drivers approval and get it in
ASAP so it finds its way in 0.9.4?
Whiteboard: r=av, sr=? [SEEKING SUPER REVIEW] → r=av, sr=waterson [SEEKING FOR DRIVERS APPROVAL]
a=roc+moz on behalf of drivers
Updated•23 years ago
|
Whiteboard: r=av, sr=waterson [SEEKING FOR DRIVERS APPROVAL] → r=av, sr=waterson, a=roc+moz
Assignee | ||
Comment 57•23 years ago
|
||
checked in
new revision: 1.9; previous revision: 1.8
resolved as fixed
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Comment 58•23 years ago
|
||
*** Bug 85580 has been marked as a duplicate of this bug. ***
Comment 59•23 years ago
|
||
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?
Assignee | ||
Comment 60•23 years ago
|
||
Jason McCormick, did you try about:plugins, what did you see?
Comment 61•23 years ago
|
||
Serge: Mozilla refuses to start until I've removed everything but the null
plug-in. Then Mozilla displays only the default plugin.
Assignee | ||
Comment 62•23 years ago
|
||
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?
Assignee | ||
Comment 63•23 years ago
|
||
Jason: could you ls -l /usr/X11R6/lib/libXt.*,
it's possible you have a wrong link for libXt.so
Comment 64•23 years ago
|
||
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.
Assignee | ||
Comment 65•23 years ago
|
||
Joson: what is the last console message you are seeing?
Comment 66•23 years ago
|
||
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•23 years ago
|
||
I'm getting this error, too.
Assignee | ||
Comment 68•23 years ago
|
||
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•23 years ago
|
||
that is bug 89499
Assignee | ||
Comment 70•23 years ago
|
||
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.
Assignee | ||
Comment 71•23 years ago
|
||
Assignee | ||
Comment 72•23 years ago
|
||
I'm reopening this.
av, waterson: I'm sorry for disappointment, and again could you r/sr= , please?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 73•23 years ago
|
||
r=av
Comment 74•23 years ago
|
||
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]
Attachment #47825 -
Flags: superreview+
a=roc+moz on behalf of drivers
Assignee | ||
Comment 76•23 years ago
|
||
checked in
/cvsroot/mozilla/modules/plugin/base/src/nsPluginsDirUnix.cpp,v <--
nsPluginsDirUnix.cpp
new revision: 1.10; previous revision: 1.9
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Comment 77•23 years ago
|
||
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.
Assignee | ||
Comment 78•23 years ago
|
||
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•23 years ago
|
||
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 81•23 years ago
|
||
Eeek, this is not on the mozilla 0.9.4 branch. Reopening.....
Status: VERIFIED → REOPENED
Keywords: nsbranch
Resolution: FIXED → ---
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Assignee | ||
Comment 82•23 years ago
|
||
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.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Target Milestone: mozilla0.9.5 → mozilla0.9.4
Comment 84•23 years ago
|
||
*** Bug 79108 has been marked as a duplicate of this bug. ***
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•