63074 - Mozilla & Java Crashes when port 13000 is blocked by firewall

Status: VERIFIED FIXED

(Core Graveyard :: Java: OJI, defect)

Description

[Stephen Moehle]

If I install the Java plugin in Mozilla, Mozilla will hang at startup.  The last
thing I see on the console is:

Registering plugin 19 for: "application/x-java-bean;version=1.3","Java(tm)
Plug-in",""
Registering plugin 20 for:
"application/x-java-bean;jpi-version=1.3.0_01","Java(tm) Plug-in",""

java_vm is running and so is mozilla-bin, but Mozilla never displays a window.
It will sit there forever or until I kill it, whichever comes first.

I installed Java by installing NS6 and copying the libjavaplugin_oji.so link
from its plugins directory to the Mozilla plugins directory.

For what it is worth, NS6 will not start either when libjavaplugin_oji.so is
present.  With it gone, both Mozilla and NS6 run fine.

Tested with Mozilla 121414 on Linux (RedHat 7).

Comment 1

[R.K.Aa.]

*** Bug 63075 has been marked as a duplicate of this bug. ***

Comment 2

[Stephen Moehle]

I have discovered why Mozilla was hanging with Java installed.  Mozilla and Java
seem to communicate through a socket.  Not a UNIX domain socket.  Rather they
use a real Internet socket on port 13000 and, as such, were running afoul of my
ipchains firewall.  I have it set to deny all SYN packets since my machine is
just a workstation and not a server of any kind.  This prevented java_vm from
connecting to the socket on which mozilla_bin was listening.

Why is a UNIX domain socket not being used?  It seems very bad to me that to use
Java, Mozilla must listen to all foreign addresses on a socket at a well known
port number.  This would seem to invite all sorts of malicious hacking
especially since most users will not realize that Mozilla is acting as a server
and may not have a firewall setup to protect themselves.

Comment 3

[Keyser Sose]

Marking WORKSFORME as per Stephen's comments. As for the question I have no
idea. I suggest filing another bug so we can get an official response.

Comment 4

[Stephen Moehle]

Created bug 63810 for the socket question.

Comment 5

[Stephen Moehle]

On second thought, I am going to reopen this bug.  Hanging is never an
acceptable response to an unexpected condition.  Mozilla should detect that it
could not open the socket and should put up a message box saying "No Java for
you" and explain why.  It should then continue load without Java.  It definitely
should not hang.  What kind of user feedback is that?

Comment 6

[Keyser Sose]

Hmmmm ok i fiddled around with the summary and went ahead and NEW'ed. Hopefully
we can get an answer on this one. I appreciate the feedback. I am going to ask
around and see what I can dig up.

Comment 7

[Keyser Sose]

Adding crash keyword

Comment 8

[Stephen Moehle]

Just to be clear: neither mozilla nor java crashes.  There is a "hang" keyword
that would probably be more appropriate than "crash".

Comment 9

[Keyser Sose]

Whoops changing to hang :)

Comment 10

[edburns]

Steve Katz, the owner of the Sun Java Plugin on Unix, tells me that this bug is 
due to the fact that NSPR uses TCP sockets by default.  If there was a way to 
get NSPR to use Unix domain sockets, this bug may not persist.  Therefore, I'm 
reassigning this to NSPR.

Comment 11

[edburns]

Reassign to NSPR owner.

Comment 12

[Wan-Teh Chang]

You can create a Unix domain socket as follows:
#include "prio.h"
#include "private/pprio.h"

PRFileDesc *sock;

sock = PR_Socket(PR_AF_LOCAL, PR_SOCK_STREAM, 0); /* a private NSPR function */

If you don't like the idea of calling a private NSPR
function, you can bypass NSPR and write standard BSD
socket code.

Comment 13

[edburns]

Hi Steve,

I know you said not to assign bugzilla bugs to you, but this is just to track in
bugzilla the bugtraq bug 4409791.  When that bug is fixed, you can close this one.  

Comment 14

[Steven Katz]

How do I go about using private nspr functions?  Where can I find the header
files that define the constants used in the code provided?  Is it likly this
interface will change in the future?

The implementation of PR_SOcket seems to create a NON-BLOCKING socket (as read
from the LXR sources in mozilla), is this the case?

My understanding is that PS_NewTCP create a BLOCKING socket, is this true?

Bypassing nspr seems like a non-starter at this point since it would mean
rewritting all the socket code we currently have.  Is there a public way to take
a socket that already exists and turn it into a PRFileDesc?  I could not find
such a thing inthe documsntation.

Comment 15

[edburns]

On 12 February 21:56:59, Wan-Teh Chang wrote:
> You can only use our semi-private functions.  These
> functions are declared in headers files under the
> "private" directory.  The function you need, PR_Socket,
> is declared in "private/pprio.h".
>
> We reserve the right to change our semi-private interface but
> in practice it's unlikely to happen.
>

> > The implementation of PR_Socket seems to create a NON-BLOCKING
> > socket (as read from the LXR sources in mozilla), is this the case?

>
> The PRFileDesc it creates is BLOCKING.  The Unix file descriptor
> (an int) embedded in the PRFileDesc is NON-BLOCKING.
>
> The non-blocking mode of the Unix file descriptor used by NSPR
> is an implementation detail.  If you need to rely on this fact,
> that's a problem.
>
> > My understanding is that PR_NewTCP create a BLOCKING socket, is this true?
>
> See above.

> > Bypassing nspr seems like a non-starter at this point since it would
> > mean rewritting all the socket code we currently have.  Is there a
> > public way to take a socket that already exists and turn it into a
> > PRFileDesc?  I could not find such a thing in the documentation.

> This is also a semi-private function, also declared in
> "private/pprio.h".  There are actually four of them: PR_ImportFile,
> PR_ImportPipe, PR_ImportTCPSocket, and PR_ImportUDPSocket.  You can
> use PR_ImportTCPSocket to import a Unix domain SOCK_STREAM socket.

> Please do not publicize our semi-private interface.

Comment 16

[Steven Katz]

A fix has been made in the ladybird (1.3.1) version of the plugin/jre.  This fix
has been confirmed by the original submitter (thanks Stephen).  The coresponding
Sun Bugtraq bug has been updated and I am marking this report as fixed.

No changes where required to the Netscape code to implement this fix.

I think in the long run it would be a benifit to NSPR if it exposed a public
interface to UNIX domain sockets.

Comment 17

[Stephen Moehle]

*** Bug 63810 has been marked as a duplicate of this bug. ***

Comment 18

[John Unruh]

Verified fixed.