[HARMONY-5876] [classlib][nio] NIO native corrupting Long.valueOf(0)

• Type: Bug
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Affects Version/s: 5.0M6
• Component/s: Classlib
• Environment: Windows x86-32 for sure, probably others.
• Assignee: Tim Ellison
• Reporter: Andrew Cornwall
• Created: 18/Jun/08 01:23
• Updated: 18/Jun/08 09:52

Description

The following test case:

import java.net.*;
import java.nio.channels.*;
public class SocketChannelTest {
public static void main(String args[]) throws Exception

{ SocketChannel socketChannel = SocketChannel.open(); socketChannel.configureBlocking(false); InetSocketAddress addr = new InetSocketAddress("127.0.0.1", 6789); System.out.println(new Long(0)); System.out.println(Long.valueOf(0)); socketChannel.connect(addr); System.out.println(new Long(0)); System.out.println(Long.valueOf(0)); }

}

will print the following output on Harmony M6:
0
0
0
598759496

On Sun JDK 1.5.0_14, it prints the expected value:
0
0
0
0

I suspect that the problem is in the NIO native code: in particular, OSNetworkSystem.c does the following:
void
setConnectContext(JNIEnv *env,jobject longclass,U_8 * context){
jclass descriptorCLS;
jfieldID descriptorFID;
descriptorCLS = (*env)->FindClass (env, "java/lang/Long");
descriptorFID = (*env)->GetFieldID (env, descriptorCLS, "value","J");
(*env)->SetLongField(env, longclass, descriptorFID,(jlong)((IDATA)context));
};

This will work as long as Longs aren't cached - but once Longs are cached for performance reasons (as they are in Harmony) modifying the value of a Long in a native may have unexpected repercussions.

I'm pretty sure this code is in error - I don't know if other native code does a similar thing.