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)
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-
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.
Comment 2•22 years ago
|
||
-> 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
Comment 3•19 years ago
|
||
*** Bug 307831 has been marked as a duplicate of this bug. ***
Comment 4•19 years ago
|
||
*** Bug 316228 has been marked as a duplicate of this bug. ***
Comment 5•19 years ago
|
||
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?
Comment 6•19 years ago
|
||
>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).
Comment 7•19 years ago
|
||
(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.
Comment 8•19 years ago
|
||
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)
You need to log in
before you can comment on or make changes to this bug.
Description
•