Closed Bug 97362 Opened 23 years ago Closed 23 years ago

Plugins have "invalid ELF header"

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: vanbalen, Assigned: srgchrpv)

References

Details

(Whiteboard: PDT+)

Attachments

(3 files, 3 obsolete files)

patch to check out soname extention
810 bytes, patch
Details | Diff | Splinter Review
with typo correction
854 bytes, patch
Details | Diff | Splinter Review
the next one
1005 bytes, patch
serhunt
: review+
waterson
: superreview+
Details | Diff | Splinter Review
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3+) Gecko/20010828 BuildID: 2001082810 I actually got this out of the 2001082809 directory but it's reporting 2001082810 as its buildID. This might also be related to bug 86591 and whatever's being done to fix it, but I didn't want to pollute that bug with possibly unrelated info so I decided to file a new bug. /*Begin bug description*/ Beginning with either today's or yesterday's builds, I now get the following when I start the browser: LoadPlugin: failed to initialize shared library /home/foobar/tar/mozilla-gcc295/plugins/nppdf.so [/home/foobar/tar/mozilla-gcc295/plugins/nppdf.so: undefined symbol: XtStrings] LoadPlugin: failed to initialize shared library /home/foobar/tar/mozilla-gcc295/plugins/raclass.zip [/home/foobar/tar/mozilla-gcc295/plugins/raclass.zip: invalid ELF header] LoadPlugin: failed to initialize shared library /home/foobar/tar/mozilla-gcc295/plugins/ShockwaveFlash.class [/home/foobar/tar/mozilla-gcc295/plugins/ShockwaveFlash.class: invalid ELF header] AFAIK, the XtStrings error is Debian specific and can usually be fixed with a symlink to said lib in MOZILLA_HOME. This is actually an improvement because, in the past, mozilla just ignored the PDF plugin. The other plugins, however, worked on the 20010826 build I was running before this one. Reproducible: Always Steps to Reproduce: Here's what I did... not necessarily exact steps: 1. Be running an older build with flash and real player plugins 2. Upgrade to one of today's builds 3. Start browser and notice that plugins no longer work Actual Results: Get error messages about ELF headers. Expected Results: plugins should register and work Here's an ls -l of my plugins dir: total 1180 -rw-r--r-- 1 foobar foobar 2363 Aug 27 11:55 ShockwaveFlash.class lrwxrwxrwx 1 foobar foobar 59 Aug 22 16:45 javaplugin_oji.so -> /usr/lib/j2sdk1.3/jre/plugin/i386/mozilla/javaplugin_oji.so -rw-r--r-- 1 foobar foobar 947992 Aug 27 11:55 libflashplayer.so -rwxr-xr-x 1 foobar foobar 19436 Aug 28 13:00 libnullplugin.so -rw-r--r-- 1 foobar foobar 74552 Aug 22 16:43 nppdf.so -rw-r--r-- 1 foobar foobar 4139 Aug 22 16:43 raclass.zip -rwxr-xr-x 1 foobar foobar 131580 Aug 22 16:43 rpnp.so
Forgot to mention the plugins still show up in about:plugins but the browser crashes when I go to a page that utilizes them.
cc serge, this seems like 69167 again?
Yes, this is valid bug, thanks. we are trying to load every file from plugins dir as shared lib, so we are getting an error about elf header for not *.so files, to eliminate the messages about ELF headers just remove all not *.so files from plugins dir for now. I'm guessing *.class and *.zip are java files for 4.x LiveConnect feature, not sure if mozilla needs its. av@netscape.com, what do you think? >3. Start browser and notice that plugins no longer work could you clarify, can you access weather.com after start mozilla, do not "about:plugins" before that please, other way you'll be hit by bug 86591
I think we should not try to load files that do not look like libraries. Is not this easy to achieve just parsing for '.so' part in the file name?
Attached patch bulletproofed version (obsolete) — — Splinter Review
I hope you don't mind a comment but names are just labels in Unix. Depending on suffixes won't always work. To do this properly, you have to open each file for reading and try to determine if it's an ELF file or not.
Yes, you're right, the crash I was seeing was bug 86591... BTW, I'm inclined to agree with tenthumbs on the files in unix issue. While most files will have the correct extension, it isn't necessarily true and opening the file to check it's type is probably, IMHO, the most fullproof way to fix this bug. OTOH, the current fix would be a quick way to get rid of the problem until something more comprehensive can be done :-)
It's more than just the name. ELF is cross-platform so you need to check if the file is correct for your platform.
tenthumbs, you are right in general, but in this particular case I disagree with you, file opening and checking its magic number is time expensive procedure, what is the reason to decrease performance here? beside, you can always use soft links.
Third-party vendors can install plugins, users can, almost anyone can. There's no reason to assume they will get it right so I think mozilla needs to protect itself from random garbage. I would think that protection is worth the cost. It should only be a few milliseconds in time. I don't understand your comment about symlinks. Mozilla shouldn't care about symlinks at all in this context. You're interested in the link target not the link. Since shared libraries need to be executable, mozilla can save some time by ignoring anything not executable by the process. That would mean doing a stat on every file in a plugin directory but that's almost always implicitly done anyway. I guess one should also worry about special (in the POSIX sense) files so I suggest an approach like this for each file: 1) stat (never lstat) the file and reject "special" and unknown files, (forget you ever heard about symlinks). 2) reject any file that is not executable (really should deal with the situation where effective uid != real uid). 3) reject any file that fails a magic number test. Anything that passes all this is probably OK. I have no idea if you want to recurse into sub-directories but that wouldn't be hard either. Yes, this is quite paranoid but you almost certainly want to be.
You are right about symlinks, and thanks for your suggestions, sure it's right thing to do in common case, but I doubt we have such case here. Of course, users can do whatever they want, they can create tons of garbage files with .so extension under plugins dir, or what else ... The point is there are well known standard file's extensions, and personally, I have not seen netscape's 4.x plugins shared lib with extension other than standard, moreover on win32 netscape's plugins file name has the mask "np*.dll" >3) reject any file that fails a magic number test. implementation of this is going to be platform (unix flavor) specific:(
*** Bug 87478 has been marked as a duplicate of this bug. ***
I agree that filenames are a decent enough solution on Unix, since we don't want to get hungup at startup time. tenthumbs, I understand your point but generally speaking, if we change libfoo.so to libfoo.bar the dynamic linker ld.so wouldn't pick it up, so why would you expect Mozilla to do so? Serge, idea looks sane to me.
Keywords: patch, review
r=av and reassigning
Assignee: av → serge
*** Bug 98025 has been marked as a duplicate of this bug. ***
I don't know if it is related but with Build 2001090308, I also get : LoadPlugin: failed to initialize shared library /usr/java/jre1.3.1/plugin/i386/ns600/libjavaplugin_oji.so [/usr/java/jre1.3.1/plugin/i386/ns600/libjavaplugin_oji.so: undefined symbol: XtShellStrings]
it's bug 69167
Let's not confuse what the compiler and the normal linker (ld) do with what the run-time dynamic linker does. The compiler does, indeed, expect a .so suffix and passes that name to ld which, in turn, knows how to handle these things. However, that doesn't mean the these files are usable by the dynamic linker. Just look at /usr/lib/libc.so on Linux. It's a text file. Guess which error message you get if you try to dlopen it. Now many, if not most, if the system library names that the dynamic linker knows about don't actually end in .so because of various naming conventions. I fail to see why "well known" extensions apply. Christian Reis: the dynamic linker only uses its search rules if it's handed relative pathnames. I don't believe mozilla does that. It shouldn't anyway. So, mozilla can load any absolute pathname it wants. Serge: most of the Linux plugins, so far, have not been versioned. If a developer decides to do that (and I see no reason why they can't or shouldn't) then such a developer may choose a version naming scheme that does not end in .so. That does raise the issue of symlinks again but I still think mozilla should ignore them. It's almost certainly more reliable to load libraries and see if their handles are the same. As for platform-specific code, all platforms that support ELF binaries can share common code because ELF binaries have a common header structure. You do need platform-specific constants but that's a configure/compile-time issue.
While I agree that opening the file is the best way to go in making sure that it's actually a library that's being loaded, it actually is a little more complex than one might think... just take a look at the code for the unix "file" utility (ftp.astron.com/pub/file/). file, of course, does a lot more than mozilla would probably have to do but still... Of course, you could always popen "file" and grep for ELF.*LSB shared object... just kidding! :-) As to having a version number included in the file name (e.g. libXt.so.6?), the regexp could be modified to account for that, methinks.
tenthumbs : >ELF binaries have a common header structure no argue, but what about ibm aix & hpux which do not use ELF?
*** Bug 98709 has been marked as a duplicate of this bug. ***
Well, i get those elf errors, but my plugins work fine, at least flash and java I dont know about realplayer
Serge: > but what about ibm aix & hpux which do not use ELF? There's always someone who has to be different. :-) I would think there are two possibilities: a) look through /etc/magic and try to fake up something with that data, b) ask the vendors, or someone else, for help, or c) don't do testing on these platforms. Somewhat off-topic, it doesn't look like mozilla checks if any library handles are the same. Am I right? If so, I think that's an error and I'll open a new bug.
This bug is present in 0.9.4 and prevents a lot of my plugins from loading properly.
My plugins load fine despite this bug. The error messages have to do with the .zip and .class files that mozilla is attempting to load like shared libs. Have you tried to use the plugins? If they don't work you may be seeing another bug or possibly have found a new one.
*** Bug 99870 has been marked as a duplicate of this bug. ***
Nope.. If i try to load a page with Macromedia flash embedded, mozilla crashes and I get some unresolved error thing.. I'm pretty sure it's the same bug though.
I'm pretty sure the warning messages have nothing to do with the crash. what is talkback ID for the crash?
I'm not using a talkback build.
Hrm. It seems the version of 0.9.4 works fine with plugins, while my compiled version does not. Oh well, forget that message about plugins not working.
*** Bug 100185 has been marked as a duplicate of this bug. ***
0.9.4 talkback binary, rh7.1 -- what I get is the error messages (one each for a .zip file from realplayer and a .class file from shockwave-flash), and when I hit a page that has a flash page on it, it says the plug-in isn't loaded (even though a later check to about:plugins says its there and working...)
what page?
*** Bug 101317 has been marked as a duplicate of this bug. ***
*** Bug 101871 has been marked as a duplicate of this bug. ***
Comment on attachment 47426 [details] [diff] [review] with typo correction >Index: nsPluginsDirUnix.cpp >=================================================================== >RCS file: /cvsroot/mozilla/modules/plugin/base/src/nsPluginsDirUnix.cpp,v >retrieving revision 1.9 >diff -u -r1.9 nsPluginsDirUnix.cpp >--- nsPluginsDirUnix.cpp 2001/08/27 22:14:52 1.9 >+++ nsPluginsDirUnix.cpp 2001/08/29 00:56:11 >@@ -323,12 +323,15 @@ > PRBool nsPluginsDir::IsPluginFile(const nsFileSpec& fileSpec) > { > const char* pathname = fileSpec.GetCString(); >- >+ if (pathname) { > #ifdef NS_DEBUG > printf("IsPluginFile(%s)\n", pathname); Re-indent this. > #endif >- >- return PR_TRUE; >+ int n = PL_strlen(pathname) - 3; Instead of hard-coding ``3'', use |sizeof(LOCAL_PLUGIN_DLL_SUFFIX) - 1| (assuming that LOCAL_PLUGIN_DLL_SUFFIX is a string literal). >+ if (n > 0 && !PL_strcmp(&pathname[n], LOCAL_PLUGIN_DLL_SUFFIX)) >+ return PR_TRUE; // *.so or *.sl file >+ } >+ return PR_FALSE; > } > > ///////////////////////////////////////////////////////////////////////////
Attachment #47426 - Flags: needs-work+
Chris, thank you, I'm updating the patch
Attached patch updated patch (obsolete) — — Splinter Review
I think the math still might be a bit off. Say the pathname is "abc.so" and the LOCAL_PLUGIN_DLL_SUFFIX is ".so". PL_strlen(pathname) == PL_strlen("abc.so") == 6 sizeof(LOCAL_PLUGIN_DLL_SUFFIX) == 4 (don't forget the '\0'!) So, n == 6 - 4 == 2 And therefore, &pathname[2] == "c.so" I think you want to do: n = PL_strlen(pathname) - (sizeof(LOCAL_PLUGIN_DLL_SUFFIX) - 1); Which in this case would lead to n == 6 - (4 - 1) == 6 - 3 == 3, and &pathname[3] == ".so".
Attached patch with updated debug output (obsolete) — — Splinter Review
Attachment #47415 - Attachment is obsolete: true
Attachment #51178 - Attachment is obsolete: true
the last one has int n = PL_strlen(pathname) - (sizeof(LOCAL_PLUGIN_DLL_SUFFIX) - 1);
Attachment 51232 [details] [diff] looks an awful lot like attachment 51178 [details] [diff] [review], but assuming you've made the change in your tree (and tested it!), r= or sr=waterson, pick one.
hmm..., it looks like somehow I'm posting the wrong file here twice:( Is browser posting from the cache? because I'm saving the diffs into the same file and I did open the first wrong file in the browser window:( the rigth (I hope) patch is following.
Attached patch the next one — — Splinter Review
finally it looks how it suppose to be:)
Attachment #51232 - Attachment is obsolete: true
Comment on attachment 51238 [details] [diff] [review] the next one sr=waterson
Attachment #51238 - Flags: superreview+
pls go ahead and check this in - tentative PDT+, pending an r=.
I realize no one's listening to me <g> but this is really the wrong way to solve this problem. Let me quote from the glibc manual: "In POSIX systems, one file can have many names at the same time. All of the names are equally real, and no one of them is preferred to the others." Names are not important. This patch will just cause problems down the road.
Comment on attachment 51238 [details] [diff] [review] the next one r=av
Attachment #51238 - Flags: review+
tenthumbs@cybernex.net: I understand your concern, and we'll definitely change the plugins registration/loading code for future releases (bug 101769), but for coming one, I think, it's worth to use this as a temporary approach to get rid of confusing messages, and speed up the start up time.
PDT+ providing seawood / mcafee can do an r= for the patch.
Whiteboard: PDT+
PDT+ providing seawood / mcafee can do an r= for the patch.
Keywords: nsbranch+
on the trunk /mozilla/modules/plugin/base/src/nsPluginsDirUnix.cpp,v <-- new revision: 1.16; previous revision: 1.15
on the MOZILLA_0_9_4_BRANCH /mozilla/modules/plugin/base/src/nsPluginsDirUnix.cpp,v <-- new revision: 1.10.2.2; previous revision: 1.10.2.1
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
serge: can you please file a bug per tenthumb's comments, and note that bug number here?
bug 102286 has been created as the descendant of this one.
error not seen on branch 1001 linux build anymore. markig verif, adding 'vtrunk'
Status: RESOLVED → VERIFIED
Keywords: vtrunk
nice... how I am getting: -- snip -- nsPluginsDirUnix.cpp Building deps for ../../../../../../../src/2001-10-01-08-trunk/mozilla/modules/plugin/base/src/nsPluginsDirUnix.cpp /opt/SUNWspro/bin/CC -o nsPluginsDirUnix.o -c -DOSTYPE=\"SunOS5\" -DOSARCH=\"SunOS\" -DMOZ_REFLOW_PERF -DMOZ_REFLOW_PERF_DSP -DOJI -D_IMPL_NS_PLUGIN -I../../../../dist/include/xpcom -I../../../../dist/include/string -I../../../../dist/include/java -I../../../../dist/include/pref -I../../../../dist/include/necko -I../../../../dist/include/gtkxtbin -I../../../../dist/include/webshell -I../../../../dist/include/caps -I../../../../dist/include/intl -I../../../../dist/include/dom -I../../../../dist/include/gfx -I../../../../dist/include/layout -I../../../../dist/include/content -I../../../../dist/include/widget -I../../../../dist/include/cookie -I../../../../dist/include/mimetype -I../../../../dist/include/oji -I../../../../dist/include/exthandler -I../../../../dist/include/docshell -I../../../../dist/include/webbrwsr -I../../../../dist/include/timer -I../../../../dist/include/windowwatcher -I../../../../dist/include/xlibrgb -I../../../../dist/include/plugin -I../../../../dist/include -I/home/mozilla/builds/2001-10-01-08-trunk/objdir_ws6_xlib/dist/include/nspr -I/usr/openwin/include -KPIC -I/usr/openwin/include -mt -O -DDEBUG -DDEBUG_mozilla -DTRACING -g -I/usr/openwin/include -DMOZILLA_CLIENT -DBROKEN_QSORT=1 -DNSCAP_DISABLE_DEBUG_PTR_TYPES=1 -DD_INO=d_ino -DMOZ_WIDGET_XLIB=1 -DMOZ_ENABLE_XREMOTE=1 -DMOZ_DEFAULT_TOOLKIT=\"xlib\" -DMOZ_X11=1 -DSTDC_HEADERS=1 -DHAVE_ST_BLKSIZE=1 -DHAVE_INT16_T=1 -DHAVE_INT32_T=1 -DHAVE_INT64_T=1 -DHAVE_UINT=1 -DHAVE_UINT_T=1 -DHAVE_UINT16_T=1 -DHAVE_DIRENT_H=1 -DHAVE_SYS_BYTEORDER_H=1 -DHAVE_MEMORY_H=1 -DHAVE_UNISTD_H=1 -DHAVE_NL_TYPES_H=1 -DHAVE_SYS_STATVFS_H=1 -DHAVE_SYS_STATFS_H=1 -DHAVE_SYS_VFS_H=1 -DHAVE_SYS_MOUNT_H=1 -DHAVE_LIBM=1 -DHAVE_LIBDL=1 -DHAVE_LIBSOCKET=1 -D_REENTRANT=1 -DHAVE_RANDOM=1 -DHAVE_STRERROR=1 -DHAVE_LCHOWN=1 -DHAVE_FCHMOD=1 -DHAVE_SNPRINTF=1 -DHAVE_LOCALTIME_R=1 -DHAVE_STATVFS=1 -DHAVE_MEMMOVE=1 -DHAVE_RINT=1 -DHAVE_NL_LANGINFO=1 -DHAVE_STRTOK_R=1 -DHAVE_IOS_BINARY=1 -DHAVE_CPP_EXPLICIT=1 -DHAVE_CPP_SPECIALIZATION=1 -DHAVE_CPP_MODERN_SPECIALIZE_TEMPLATE_SYNTAX=1 -DHAVE_CPP_PARTIAL_SPECIALIZATION=1 -DHAVE_CPP_ACCESS_CHANGING_USING=1 -DHAVE_CPP_AMBIGUITY_RESOLVING_USING=1 -DHAVE_CPP_NAMESPACE_STD=1 -DHAVE_CPP_UNAMBIGUOUS_STD_NOTEQUAL=1 -DHAVE_CPP_NEW_CASTS=1 -DHAVE_CPP_DYNAMIC_CAST_TO_VOID_PTR=1 -DNEED_CPP_UNUSED_IMPLEMENTATIONS=1 -DHAVE_I18N_LC_MESSAGES=1 -DMOZ_LOGGING=1 -DMOZ_ENDER_LITE=1 -DNS_MT_SUPPORTED=1 -DIBMBIDI=1 -DSUNCTL=1 -DACCESSIBILITY=1 -DDETECT_WEBSHELL_LEAKS=1 -DMOZ_USER_DIR=\".mozilla\" -DMOZ_XUL=1 -DINCLUDE_XUL=1 -DMOZ_MATHML=1 -DMOZ_SVG=1 -DUSE_IMG2=1 -DMOZ_DLL_SUFFIX=\".so\" -DXP_UNIX=1 -DUNIX_ASYNC_DNS=1 -DJS_THREADSAFE=1 ../../../../../../../src/2001-10-01-08-trunk/mozilla/modules/plugin/base/src/nsPluginsDirUnix.cpp "../../../../../../../src/2001-10-01-08-trunk/mozilla/modules/plugin/base/src/nsPluginsDirUnix.cpp", line 342: Error: LOCAL_PLUGIN_DLL_SUFFIX is not defined. "../../../../../../../src/2001-10-01-08-trunk/mozilla/modules/plugin/base/src/nsPluginsDirUnix.cpp", line 343: Error: LOCAL_PLUGIN_DLL_SUFFIX is not defined. 2 Error(s) detected. gmake[2]: *** [nsPluginsDirUnix.o] Error 2 gmake[2]: Leaving directory `/home/mozilla/builds/2001-10-01-08-trunk/objdir_ws6_xlib/modules/plugin/base/src' gmake[1]: *** [install] Error 2 gmake[1]: Leaving directory `/home/mozilla/builds/2001-10-01-08-trunk/objdir_ws6_xlib/modules/plugin' gmake: *** [install] Error 2 -- snip -- ;-((
s/how/now/
my bad:( there is a new bug 102652, with the patch in.
> there is a new bug 102652, with the patch in. Thanks!
Would just like to note that this patch breaks the loading of the java plugin on AIX. The java plugin is named libjavaplugin_oji.a (".a" instead of ".so" suffix), so the java plugin fails to load.
Yes, libjavaplugin_oji.a is not recognizable as a plugin lib with this patch, cc: jdunn Jim, I've checked out some other mozilla's aix shared libs, all have suffix ".so" why this one has ".a"? Is it possible to change this suffix?
The AIX Java team plans to rename the AIX Mozilla Java plugin to libjavaplugin_oji.so with the next major new Java release. It is not possible to rename the file in the existing releases (Java 1.3.0 and Java 1.3.1).
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: