Mozilla & Java Crashes when port 13000 is blocked by firewall

VERIFIED FIXED

Status

--
major
VERIFIED FIXED
18 years ago
8 years ago

People

(Reporter: smoehle, Assigned: steve.katz)

Tracking

({hang})

Trunk
x86
Linux

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

18 years ago
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

18 years ago
*** Bug 63075 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 2

18 years ago
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

18 years ago
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 4

18 years ago
Created bug 63810 for the socket question.
(Reporter)

Comment 5

18 years ago
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?
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---

Comment 6

18 years ago
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.
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Mozilla hangs at startup with Java installed. → Mozilla & Java Crashes when port 13000 is blocked by firewall
Target Milestone: --- → mozilla0.8

Comment 7

18 years ago
Adding crash keyword
Keywords: crash
(Reporter)

Comment 8

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

Comment 9

18 years ago
Whoops changing to hang :)
Keywords: crash → hang

Comment 10

18 years ago
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.
Component: OJI → NSPR
Product: Browser → NSPR
Target Milestone: mozilla0.8 → ---
Version: other → 4.1

Comment 11

18 years ago
Reassign to NSPR owner.
Assignee: edburns → wtc
QA Contact: shrir → wtc

Updated

18 years ago
Assignee: wtc → edburns
Component: NSPR → OJI
Product: NSPR → Browser
QA Contact: wtc → shrir
Version: 4.1 → other

Comment 12

18 years ago
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

18 years ago
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.  
Assignee: edburns → skatz
(Assignee)

Comment 14

18 years ago
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

18 years ago
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.
(Assignee)

Comment 16

18 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED
(Reporter)

Comment 17

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

Comment 18

18 years ago
Verified fixed.
Status: RESOLVED → VERIFIED

Updated

8 years ago
Component: Java: OJI → Java: OJI
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.