197855 - [UNIX] JRE 1.3.1 crashes because we don't resolve symbolic links to plugin before loading it

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect, P2)

Description

[Tracy Walker [:tracy]]

seen on linux commercial 2003-03-17-05-trunk

-install the build usign the Full installation
-launch the app.
-goto the java.sun.com/applets page and click on an applet to run (a simple and
quick one is LED, under Applet Archive)

The browser quits; no talkback generated. The follow appears in the console:

INTERNAL ERROR on Browser End: Exec of "java_vm" failed: 2
<
System error?:: No such file or directory
Gdk-ERROR **: Fatal IO error 9 (Bad file descriptor) on X server :0.0.
INTERNAL ERROR on Browser End: Could not read ack from browser
System error?:: Resource temporarily unavailable

Comment 1

[Frederic Bezies]

1) mozilla is now build using gcc 3.2.x, not Java.
2) Go to Blackdown.org and download a jre from there
3) install it and try to see if it is working.

Bug duplicate of bug 197360 ?

Comment 2

[Boris Zbarsky [:bzbarsky]]

> 1) mozilla is now build using gcc 3.2.x, not Java.

The RPM builds are.  The installer and tarball are NOT.

Comment 3

[Matthias Versen [:Matti]]

and it wouldn't crash mozilla if the build would be compiled with gcc3.2 
(but they are not)

Comment 4

[Frederic Bezies]

Sorry for the mistake. I am lost in all linux versions ! :-/

Comment 5

[timeless]

tracy: can you strace mozilla?
./run-mozilla.sh /usr/bin/strace -f -ff -q -o log197855 ./mozilla-bin

Comment 6

[Peter Lubczynski]

This WFM with JRE 1.4.1 with bits dated 17-Mar-2003 08:49 from:
http://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-i686-pc-linux-gnu.tar.gz

...checking NSCP commercial

Comment 7

[Heikki Toivonen (remove -bugzilla when emailing directly)]

I see this on RH 8.0, downloaded Mozilla nightly, went to LED page, got dialog I
don't have the plugin, clicked ok to get the plugin, it installed 1.3.1_02-b02,
and now I crash on the LED page.

Comment 8

[Tracy Walker [:tracy]]

the log from the strace is too big to be attached here.  

Comment 9

[Heikki Toivonen (remove -bugzilla when emailing directly)]

I installed Mozilla as root into /usr/local/mozillatest. I first run it as
regular user, but it wouldn't install the Java plugin. I then run it as root,
and installed the plugin. The plugin was installed in
/usr/local/mozillatest/plugins (the linked .so), and the actual stuff is in
/usr/local/mozillatest/plugins/java2).

Comment 10

[Doug Turner (:dougt)]

right now we know that 1.3.1 crashes and 1.4.x doesn't.

Comment 11

[Peter Lubczynski]

JRE 1.3.1 crashes my mozilla build from today too. However it works in a build
from the 11th. 

1.4.1 seems to work today but commercial still ships 1.3.1. Interesting that the
1.3 plugin seems to be in a ns600 directory while the 1.4.1 is in a ns6100
directory.

Be sure if you are debugging this that you compiled with gcc2.

Comment 12

[Peter Lubczynski]

Attachment: strace

here's the strace for comment #5

Comment 13

[Heikki Toivonen (remove -bugzilla when emailing directly)]

I am downgrading this to critical so that we can open the tree. The workaround
is to install a newer Java plugin (JRE).

However, we need to find out if we can prevent the crash in the plugin on our
side for the older plugins as well. If that is not feasible, then we need to
make sure that a working plugin will be installed, or available for install from
the "plugin finder plugin", and document the problems with older Java plugins in
the 1.4a and forward release notes.

Comment 14

[Peter Lubczynski]

oops, caused a mid-air

Comment 15

[Joshua Xia]

according to Comment1:
"INTERNAL ERROR on Browser End: Exec of "java_vm" failed: 2
<
System error?:: No such file or directory"

This should be the problem of java plugin 's installation.

For jre1.3.1 on linux, you should create symbolic link to
jre/plugin/i386/ns600/libjavaplugin_oji.so in mozilla's plugins directory.

Comment 16

[Heikki Toivonen (remove -bugzilla when emailing directly)]

That symbolic link is there, installed properly.

Comment 17

[Peter Lubczynski]

Okay, I downloaded the Java 1.3.1 source from Sun and searched for one of the
errors coming out to the console: "Could not read ack from browser". This error
happens just after the point where the VM gets the path to the plugin from
dladdr() in JavaVM5.cpp. 

Looking at Dougt's changes, at about:plugins with the pref
plugin.expose_full_path active, and putting in some printf's, I think the
problem is being caused from not resolving the path to symbolicly linked plugin
before calling dlopen(). When I put a call to |Normalize| in
|nsPluginHostImpl::ScanPluginsDirectory|, this crash goes away.

I'll attach a patch to this bug shortly with that fix along with the fix to bug
197975.

Comment 18

[Peter Lubczynski]

Attachment: patch v.1

Comment 19

[Tracy Walker [:tracy]]

was the patch checked in?  I haven't crashed on a java applet with linux in
several days.  The browser pops up the get plugin dialog as expected.

Comment 20

[David G King]

Looks to me like it was checked in (at least from a quick look at the first part
of the patch).

Comment 21

[Peter Lubczynski]

oops, forgot to mark FIXED along with bug 197975.

Comment 22

[Tracy Walker [:tracy]]

Thanks Peter.

verified.