|Summary:||sun's java 1.4.2_08 can't open network sockets|
|Product:||[Fedora] Fedora||Reporter:||Noa Resare <noa>|
|Component:||glibc||Assignee:||Jakub Jelinek <jakub>|
|Status:||CLOSED DUPLICATE||QA Contact:||Brian Brock <bbrock>|
|Version:||4||CC:||boris, tibbs, vnasardinov|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2005-07-12 10:45:25 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Noa Resare 2005-07-12 07:01:06 UTC
Description of problem: Sun's latest patchlevel of it's 1.4.2 java software can not open network sockets on FC4. In java 1.5 it works as expected, but unfortunately lots of software require java 1.4 to function. Version-Release number of selected component (if applicable): j2sdk-1.4.2_08-fcs (x86) glibc-2.3.5-10 (x86, x86_64) kernel-smp-2.6.12-1.1390_FC4 (x86_64) How reproducible: always Steps to Reproduce: 1. fetch and install j2sdk-1.4.2_08 from java.sun.com 2. compile and run the attached small program 3. Actual results: Exception in thread "main" java.net.SocketException: Invalid argument or cannot assign requested address at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:171) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158) at java.net.Socket.connect(Socket.java:452) at java.net.Socket.connect(Socket.java:402) at java.net.Socket.<init>(Socket.java:309) at java.net.Socket.<init>(Socket.java:124) at SocketTest.main(SocketTest.java:8) Expected results: nothing, or perhaps a ConnectException: Connection refused if you don't have a listening sshd on localhost. Additional info: I understand that this is probably Sun's fault, but if there is a simple change to be made to the glibc that fixes this perhaps it would be a good idea since a lot of us in the RealWorld^tm are stuck with needing to run sun's 1.4 java and the proabability of Sun fixing their software in a reasonable timeframe is approaching zero.
Comment 1 Jakub Jelinek 2005-07-12 10:45:25 UTC
glibc is not going to put in workarounds for bogus programs. You really have to take this with Sun.
Comment 2 Noa Resare 2005-07-12 11:36:34 UTC
I have reported this issue to Sun. Is there any way of finding out how the glibc api is used by a binary program? If I could point out exactly what they do wrong perhaps this problem can be fixed a bit faster.
Comment 3 Jakub Jelinek 2005-07-12 11:38:49 UTC
You can try tracing the program with strace -f, if the call to glibc function is done from the program and not from shared libraries it uses, you can use ltrace as well. And of course there is gdb.
Comment 4 Noa Resare 2005-07-26 14:30:13 UTC
FYI my attempts to pinpoint the problem failed. I filed an error report with sun on 050712 with internal review ID 488634. It has not yet been turned into a web searchable bug. The email with the report confirmation states that there is a three week response time, so perhaps we'll have a bug report in a week. In light of this it becomes obvious what a great job the redhat people are doing with their product. Thanks!
Comment 5 Noa Resare 2005-07-28 07:51:47 UTC
Just for the lurkers, i got a response from sun today stating that passing -Djava.net.preferIPv4Stack=true java works around the problem.
Comment 6 Jesus Salvo Jr. 2005-07-30 14:37:30 UTC
Thought I'd chip in the solution this: http://wiki.astrogrid.org/bin/view/Deploy/IPV6Warning
Comment 7 Boris Folgmann 2005-08-24 09:38:37 UTC
I doubt that this is a glibc problem! On FC3 with glibc-2.3.5-0.fc3.1 and kernel-2.6.11-1.35_FC3 everything works fine. But installing kernel-2.6.12-1.1372_FC3 brakes Java's TCP implementation. Please see bug #163650 and fix it.
Comment 8 Noa Resare 2005-08-25 18:34:56 UTC
*** This bug has been marked as a duplicate of 163650 ***