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)

x86
Linux
defect

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)

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.
setting status to new
Status: UNCONFIRMED → NEW
Ever confirmed: true
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."; ?
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.
Right. I overlooked that line. r=av
*** Bug 72130 has been marked as a duplicate of this bug. ***
Reassigning to serge and moving to m0.9.
Assignee: av → serge
Target Milestone: --- → mozilla0.9
moving to m0.9.1
Target Milestone: mozilla0.9 → mozilla0.9.1
Blocks: 79108
Target Milestone: mozilla0.9.1 → mozilla1.0
Serge, did you ever check this in?
No, I did not. TM==1.0
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)
See bug 84427 for a possible solution.
Actually, the patch in 84427 wouldn't solve this problem. See bug 74938 for info about the acrobat problem.
*** Bug 85049 has been marked as a duplicate of this bug. ***
*** Bug 80459 has been marked as a duplicate of this bug. ***
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
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
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! :-)
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.
Status: RESOLVED → REOPENED
Keywords: approval
Resolution: DUPLICATE → ---
Whiteboard: r=av, sr=?
*** Bug 88481 has been marked as a duplicate of this bug. ***
*** Bug 91302 has been marked as a duplicate of this bug. ***
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...
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?
Removing my r= from the Status line since it was for the older patch.
Whiteboard: r=av, sr=? → r=?, sr=?
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=?
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
2. sure, tough it'll slightly increase binary footprint. 4. agree
Attached patch with all av's issues resolved (deleted) — Splinter Review
shaver, do you have any thoughts on this?
*** Bug 79124 has been marked as a duplicate of this bug. ***
*** Bug 95096 has been marked as a duplicate of this bug. ***
*** Bug 95169 has been marked as a duplicate of this bug. ***
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?
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).
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
Using popen() is completely unacceptable to me. Please find another method.
agreed, the patch w/o popen is following
Attached patch without popen() (deleted) — Splinter Review
Attached patch the same as above with -u (deleted) — Splinter Review
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?
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! )
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.
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.
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.
*** Bug 96004 has been marked as a duplicate of this bug. ***
*** Bug 95901 has been marked as a duplicate of this bug. ***
*** Bug 65055 has been marked as a duplicate of this bug. ***
Is this going to make mozilla0.9.4 today? It still needs a super review.
Something like 12 dups here.....marking mostfreq
Keywords: approvalmostfreq, patch
Whiteboard: r=av, sr=? → r=av, sr=? [SEEKING SUPER REVIEW]
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 !
the fix allows to load any libs in any order.
Sure, this looks fine to me. sr=waterson
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]
Whiteboard: r=av, sr=waterson [SEEKING FOR DRIVERS APPROVAL] → r=av, sr=waterson, a=roc+moz
checked in new revision: 1.9; previous revision: 1.8 resolved as fixed
Status: REOPENED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
*** Bug 85580 has been marked as a duplicate of this bug. ***
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?
Jason McCormick, did you try about:plugins, what did you see?
Serge: Mozilla refuses to start until I've removed everything but the null plug-in. Then Mozilla displays only the default plugin.
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?
Jason: could you ls -l /usr/X11R6/lib/libXt.*, it's possible you have a wrong link for libXt.so
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.
Joson: what is the last console message you are seeing?
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.
I'm getting this error, too.
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.
that is bug 89499
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.
I'm reopening this. av, waterson: I'm sorry for disappointment, and again could you r/sr= , please?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
r=av
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+
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 ago23 years ago
Resolution: --- → FIXED
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.
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?
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
marking verif.
Status: RESOLVED → VERIFIED
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
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 ago23 years ago
Resolution: --- → FIXED
Target Milestone: mozilla0.9.5 → mozilla0.9.4
works on branch now 0925.VERIF
Status: RESOLVED → VERIFIED
*** Bug 79108 has been marked as a duplicate of this bug. ***
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: