Closed Bug 177268 Opened 22 years ago Closed 22 years ago

Not SYMlinking Sun's Java plugin makes Mozilla crash

Categories

(Core Graveyard :: Java: OJI, defect)

x86
Linux
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: ehaase, Assigned: joe.chou)

References

Details

(Keywords: crash)

User-Agent:       Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.1) Gecko/20020826
Build Identifier: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.1) Gecko/20020826

Actually, this can well be seen as a bug ni the plugin. However,
Sun seems to follow the Symlink in the plugin directory to actually
find the JRE's directory (libraries etc).
If one hard-links the plugin into the plugin directory or copies it,
Mozilla will crash.
IMHO "crashing" is not the correct answer when "java_vm" can for some
reason not be executed (it seems the libs are not found and after adding
the paths to LD_LIBRARY_PATH there are still some symbols missing,
java_vm complains).
My java JRE is java version "1.4.0_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0_01-b03)
Java HotSpot(TM) Client VM (build 1.4.0_01-b03, mixed mode)


Reproducible: Always

Steps to Reproduce:
1.Make sure the user-based or global plugin dir doesn't have any java plugins in it.
2.Get some late JRE from Sun, presumably the one above.
3.copy libjavaplugin_oji.so into the plugin dir and go to a java-enabled web site.

Actual Results:  
Moz crashes.

Expected Results:  
Open a requester and tell me the plugin did not work correctly.


-not needed, because completely reproducible-
Keywords: crash
Confirmed that mozilla does crash.

Of course a hardlink will not work since there is no posix libc api to
resolve a hard link in order to find the jvm.

Agree that this should/could be handled more elegantly.
-> invalid

The plugin can't find the JVM if you copy it.
The plugins calls a simple exit() and mozilla can't survive this because plugins
are runing in the same process.
There is also a note in the release notes that you MUST symlink the plugin
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → INVALID
*** Bug 307831 has been marked as a duplicate of this bug. ***
*** Bug 316228 has been marked as a duplicate of this bug. ***
Shameless copy;

The fact that firefox 1.0.x does not crash with a copied (not
symlinked) .so does seem to indicate a new backward-compat problem...

Alternatively, it may be acceptable if the ditros had a README and/or script in
the plugins diretory (which FF 1.5 currently does not) that recommends symlink vs. copy, or if a app-message did (before the crash :-).

I just investigated how our bretheren handle the Java plugin for
Konqueror/KHTML...

They have a 'java' settings panel, and in there one can specify the path to the
java executable. Thereafter, their system apparently locates the plugin and
applets run with full scriptability, etc. I did not test to see if java worked
before defining the fully qual'd path, but theoretically if the java executable
is on the PATH it could resolve as well...

This seems like the more modern approach to finding a JVM-plugin, vs. having to
copy/symlink shared libs, though (from what little I know about moz core),
Firefox would need code to specifically search for java plugin (which it does
not currently, only Seamonkey does?) Does anyone know of a bug/rfe that I could
watch relating to auto java plugin detection in FF?
>The fact that firefox 1.0.x does not crash with a copied (not
>symlinked) .so does seem to indicate a new backward-compat problem...

Every Firefox should crash with a copied file. As you can see at this bug this has been reported 2002 and this is not the first Report for this, only a dupe target. 

>Alternatively, it may be acceptable if the ditros had a README and/or script in
>the plugins diretory (which FF 1.5 currently does not) that recommends symlink
>vs. copy, or if a app-message did (before the crash :-).

Ask your Dirstro if you want that or ask sun to add a note to their plugin or change their plugin to not call exit().
It's a problem with the Java plugin itself that can't find the JVM and calls exit() which must crash Mozilla/Seamonkey/Firefox becuase plugins are running in the same process.

Only Mozilla/Seamonkey/Firefox on windows are doing plugin autosearch (AFAIK) but it's not problem on windows because the Java Plugin finds the JVM with the Windows registry (you can copy it on windows).
(In reply to comment #6)
> >The fact that firefox 1.0.x does not crash with a copied (not
> >symlinked) .so does seem to indicate a new backward-compat problem...
> 
> Every Firefox should crash with a copied file. 

But newer ones (prior to FF 1.5) definately do not. Someone apparently 'improved' the engine used in earlier FF/ and seamonkey, because I do have a copy of the shared lib in plugins/ in that versions (and it works). 

I not asserting that this is preferable vs a symlink, but I am asserting that there has been a regression (note how this bug started getting dups just with recent builds) and that it will cause compatibility problems for users who upgrade and who did not use a symlink. Also, other plugins that *do* support copying set an unavoidable and ongoing precedence.
Perhaps recent (6 months ago and prior) Moz plugin engines were adding/using the PATH envvar to allow the jvm-so to locate the jvm? But not in the latest builds?

Since the environment table is essentially the Unix equiv of the registry, and in this case searching PATH or even CLASSPATH should allow the plugin-so to resolve its jvm location. (the plugin .so almost certainly does this heavy lifting internally) (auto resolve via $PATH is the only way I could expect my ealier Moz builds to be working so well)
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.