Closed Bug 297807 Opened 19 years ago Closed 19 years ago

Java 1.4.2 SR2 plug-in and later cause Mozilla to crash

Categories

(Core Graveyard :: Plug-ins, defect)

Other
AIX
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: pkwarren, Assigned: pkwarren)

Details

(Keywords: crash, fixed-aviary1.0.5, fixed1.7.9)

Attachments

(2 files)

In the soon to be released Java 1.4.2 SR2 for AIX, the behavior of Java has
changed. The loadquery() function is no longer used to determine the path of the
installed JVM, so the Java plug-in fails to find the necessary libraries needed
for Java to run, and Mozilla crashes with the following error message when
viewing a page with a Java applet:

"Error: could not find libjavaplugin_oji.so
Plugin: can't find plugins/../java directory
INTERNAL ERROR on Browser End: Could not start JavaVM!

System error?:: A file or directory in the path name does not exist."

The workaround for this issue is to explicitly set the LIBPATH environment
variable to include the jre/bin and jre/bin/classic directories of the JVM (by
default these are in /usr/java14/jre/bin and /usr/java14/jre/bin/classic).
However, we can work around this issue by adding a fix to
nsPluginFile::LoadPlugin to set the LIBPATH variable before loading the Java
plug-in.
Attached patch Patch v1Splinter Review
Comment on attachment 186357 [details] [diff] [review]
Patch v1

r=mkaply

Let's put some text in the big AIX section as to why this is needed.
Attachment #186357 - Flags: review+
Attachment #186357 - Flags: superreview?(darin)
Comment on attachment 186357 [details] [diff] [review]
Patch v1

>Index: modules/plugin/base/src/nsPluginsDirUnix.cpp

>+static void setJavaLibPath(const nsCString & pluginPath)

nit: space before or after "&" but not both


>+    javaDir += NS_LITERAL_CSTRING("/classic");

nit: the preferred string juju is

      javaDir.AppendLiteral("/classic");


>+        newLibPath += ":";

nit: prefer this form

	  newLibPath.Append(':');


>+        newLibPath += ":";

ditto


>+    // Set the LIBPATH to include the path to the JRE directories
>+    javaLibPath = PR_smprintf("LIBPATH=%s", newLibPath.get());
>+    if (javaLibPath) {
>+        LOG(("AIX: new LIBPATH=%s\n", newLibPath.get()));
>+        PR_SetEnv(javaLibPath);
>+    }

So, this never frees javaLibPath, which is of course a requirement
when calling PR_SetEnv.  How often will setJavaLibPath be called?
Hopefully only once per browser session right?	At least you should
comment that we are "leaking" javaLibPath because we have to or some
comment to that effect.

I don't know if it is convention for this code or not, but usually
functions begin with an upper case variable, so SetJavaLibPath is
probably a better name for this function.


>+    NS_NAMED_LITERAL_CSTRING(javaPluginPrefix, "libjavaplugin_oji");
>+    nsCAutoString leafName;
>+    rv = mPlugin->GetNativeLeafName(leafName);
>+    if (NS_FAILED(rv))
>+        return rv;
>+
>+    if (javaLibPath == NULL && StringBeginsWith(leafName, javaPluginPrefix)) {
>+        setJavaLibPath(path);
>+    }
>+#endif

nit: move NS_NAMED_LITERAL_CSTRING down to where it is used, or maybe just
replace it with NS_LITERAL_CSTRING.


sr=darin
Attachment #186357 - Flags: superreview?(darin) → superreview+
Attached patch Patch v2Splinter Review
Nits addressed.
Attachment #186368 - Flags: superreview?(darin)
Attachment #186368 - Flags: review?(mozilla)
Attachment #186368 - Flags: review?(mozilla) → review+
Attachment #186368 - Flags: approval1.8b3?
Attachment #186368 - Flags: approval1.7.9?
Attachment #186368 - Flags: approval-aviary1.0.5?
Attachment #186368 - Flags: superreview?(darin) → superreview+
Attachment #186368 - Flags: approval1.8b3? → approval1.8b3+
Fixed on trunk.

Checking in nsPluginsDirUnix.cpp;
/cvsroot/mozilla/modules/plugin/base/src/nsPluginsDirUnix.cpp,v  <-- 
nsPluginsDirUnix.cpp
new revision: 1.37; previous revision: 1.36
done
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Comment on attachment 186368 [details] [diff] [review]
Patch v2

important for branches as well.
Attachment #186368 - Flags: approval1.7.9?
Attachment #186368 - Flags: approval1.7.9+
Attachment #186368 - Flags: approval-aviary1.0.5?
Attachment #186368 - Flags: approval-aviary1.0.5+
Fixed on Mozilla 1.7 branch for 1.7.9.

Checking in nsPluginsDirUnix.cpp;
/cvsroot/mozilla/modules/plugin/base/src/nsPluginsDirUnix.cpp,v  <-- 
nsPluginsDirUnix.cpp
new revision: 1.34.14.1; previous revision: 1.34
done
Keywords: fixed1.7.9
Fixed on aviary branch.

Checking in nsPluginsDirUnix.cpp;
/cvsroot/mozilla/modules/plugin/base/src/nsPluginsDirUnix.cpp,v  <-- 
nsPluginsDirUnix.cpp
new revision: 1.34.28.1; previous revision: 1.34
done
Missed one change when backporting to 1.7 branch which was checked in afterwards
(since AppendLiteral isn't defined on 1.7 branch):

Index: nsPluginsDirUnix.cpp
===================================================================
RCS file: /cvsroot/mozilla/modules/plugin/base/src/nsPluginsDirUnix.cpp,v
retrieving revision 1.34.28.1
diff -u -r1.34.28.1 nsPluginsDirUnix.cpp
--- nsPluginsDirUnix.cpp        20 Jun 2005 23:13:45 -0000      1.34.28.1
+++ nsPluginsDirUnix.cpp        20 Jun 2005 23:22:50 -0000
@@ -321,7 +321,7 @@
     // Check for existance of jre/bin/classic dir, and append it to
     // LIBPATH if found
     PRFileInfo info;
-    javaDir.AppendLiteral("/classic");
+    javaDir.Append(NS_LITERAL_CSTRING("/classic"));
     if (PR_GetFileInfo(javaDir.get(), &info) == PR_SUCCESS &&
         info.type == PR_FILE_DIRECTORY)
     {
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: