JDK-4874934 : EXCEPTION_ACCESS_VIOLATION in java.net.Inet4AddressImpl.lookupAllHostAddr
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 1.4.1_02
  • Priority: P3
  • Status: Closed
  • Resolution: Not an Issue
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2003-06-05
  • Updated: 2003-09-26
  • Resolved: 2003-09-26
Related Reports
Relates :  
Relates :  
This application uses JXTA for P2P file sharing.  It is a native Windows application that uses JNI to invoke a JVM.  If a user attempts to create a share through the application's GUI, several Java API methods are called, eventually returning the hostname and IP address of the local host.  

This action seems to always work properly the first time.  However, if additional attempts are made to create the same share, the JVM will crash with an EXCEPTION_ACCESS_VIOLATION reported in the native code.  Several Hotspot error logs are attached.

The JVM is 1.4.1_02.  1.4.1_03 has also been tested without success.  The only options passed to the JVM when it is created are -D options, so the Client JVM is being used.  This problem has been seen on Windows 2000 SP3.  No other configurations have been tested.

This problem began to occur last week.  No changes in code or configuration have been identified.  The problem is reproducible, and has been tested on several systems in the customer's lab.  No test case is available due to intellectual property issues.

EVALUATION Need more information. Without a test case or access to customer machines, or at least more detailed information, impossible to make a diagnosis. Try running with -Xint. If that works then the problem is in the generated code for some Java method and we can narrow it down. If this doesn't help, run with -Xcheck:jni. If errors are reported (unclear based on the bug report whether there is native code in the customer's application) then these are the cause of the problem and are in customer code. ###@###.### 2003-06-05 the dump with -Xcheck:jni failed on function: checkArray when it is calling Java_java_net_SocketInputStream_socketRead0: 0150a07c 0eeff72c 00000008 jvm!checkArray+0x1f 0150a07c 0eeff72c 00000000 jvm!checked_jni_SetByteArrayRegion+0x27 WARNING: Stack unwind information not available. Following frames may be wrong. 0150a07c 0eeff734 00000f9c net!Java_java_net_SocketInputStream_socketRead0+0x118 0000ea60 00000005 00000000 0x1727624 .... The behavior is strange, see the attached file eval.txt. We have reason to question hardware problem here. ###@###.### 2003-06-26 The problem is in MS code, on the failure thread stack, the arguments from Java are two parameters: buffer and len, we allocate the buffer on stack, then pass them into Windows API. Just before calling into Win32 API, the first parameter, the buffer address on stack is NULL, but other parameters are correct: the len of the buffer and the return address in calling function. See attachment for the stack analysis. ###@###.### 2003-09-25