JDK-5072683 : JDK1.4.2_05 (for windows, IA64) doesn't pass expr15802m445 in jck14a-compiler
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 1.4.2_05
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_2003
  • CPU: x86
  • Submitted: 2004-07-12
  • Updated: 2012-10-08
  • Resolved: 2004-08-17
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.4.2_06 06Fixed
Description
A customer found Jdk1.4.2_05(windows, IA64) doesn't pass the expr15802m445
in jck142-compiler.


CONFIGURATION:
 JCK     : jck14a-compiler
 Routine : lang\EXPR\expr158\expr15802m445\expr15802m445.java
 OS      : Windows2003(Japannese)
 JDK     : jdk1.4.2_05( windows edition for IA64 )
 MPU     : Itenium2

====================================================================


Came up with the following findings:

1. I have verified that this bug is not reproducible on solaris, using the 64 bit JVM, and 
the server-mode compiler. The command below does-not crash, on solaris:
j2sdk1.4.2_06/bin/javac -J-d64 -J-server expr15802m445.java

2. The JVM on Itanium2 is a 64-bit JVM, using the server-mode compiler.

3. The javac code-base is nearly all "java-code".

4. The command "javac -J-Xint expr15802m445.java" on Itanium2 *does-not* crash.

5. The javac command internally invokes the jvm that compiles the class-files implementing the javac-functionality, and the thus generated machine-code causes the crash.

6. FACT number 4 above confirms the finding in point No. 5 above.

7. The Command: "javac -J-XX:CompileOnly=xxx expr15802m445.java" doesnot crash either.

8. the command: "javac -J-XX:CompileOnly=com/sun/tools/javac/v8/util/List.nonEmpty expr15802m445.java" crashes with a segmentation fault identically.

9. the command: "javac -J-XX:CompileOnly=com/sun/tools/javac/v8/util/ListBuffer.append expr15802m445.java" crashes with a segmentation fault identically.

10. Similarly, the command: "javac -J-XX:CompileOnly=java/lang/StringBuffer.append expr15802m445.java" crashes with a segmentation fault identically.

11. Finally the command "javac -J-XX:+ShowMessageBoxOnError -J-XX:+PrintCompilation -J-XX:CompileOnly=java/lang/String expr15802m445.java" also crashes, in-spite of having a .hotspot_compiler file in the CWD with the following three (3 only) lines:
exclude java/lang/StringBuffer append
exclude com/sun/tools/javac/v8/util/ListBuffer append
exclude com/sun/tools/javac/v8/util/List

12. The problem discussed above *does* reproduce with the use of the "-J-XX:-UseCompilerSafepoints" flag. This fact, and the facts from points 4, and 7 above lead us to believe that this bug has to do solely with the code generated by the Server-mode compiler when invoked on the Itenium2, in 64-bit mode.
==================
###@###.### 2004-08-03

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.2_06 generic FIXED IN: 1.4.2_06 INTEGRATED IN: 1.4.2_06
2004-09-08

EVALUATION No similar bug report exists for 1.5, so I will assume this is a 1.4.2_05 only issue. Only escalated issues will be fixed in 1.4.2, so I'm closing this bug. However, you, the customer, can escalate this issue through your support organization. ###@###.### 2004-07-13 This seems to be a case of "server-compiler on IteniumII, generates bad instructions, causing javac crash". ###@###.### 2004-08-03 the crash is because the function "bang_stack_shadow_pages" causes an exception, and our exception handler doesnt want to handle it. some details from a debugging session: thread stack base is 0x6fbffe90000 thread stack limit is 0x100000 access violation address is 0x6fbffe73508 StackRedPages=2 StackYellowPages=2 StackShadowPages=6 page size is 8192 access violation address hasnt reached the yellow pages. in os_win32.cpp, it seems moving the following code from the "if (in_java)" branch clears the problem. } } else if (exception_code == EXCEPTION_ACCESS_VIOLATION) { // Either stack overflow or null pointer exception. + #ifdef _M_IA64 + PEXCEPTION_RECORD exceptionRecord = exceptionInfo->ExceptionRecord; + address addr = (address) exceptionRecord->ExceptionInformation[1]; + if (addr > thread->stack_yellow_zone_base() && addr < thread->stack_base()) { + addr = (address)((uintptr_t)addr & + (~((uintptr_t)os::vm_page_size() - (uintptr_t)1))); + os::commit_memory( (char *)addr, thread->stack_base() - addr ); + return EXCEPTION_CONTINUE_EXECUTION; + + } + #endif + if (in_java) { PEXCEPTION_RECORD exceptionRecord = exceptionInfo->ExceptionRecord; address addr = (address) exceptionRecord->ExceptionInformation[1]; ###@###.### 2004-08-06
2004-08-06

WORK AROUND use the command line flag "-J-Xint" when invoking javac on the Itenium2 Platform. ###@###.### 2004-08-03 Another workaround is to have the following lines pasted into a ".hotspot_compiler" file located in the CWD of the javac invocation. exclude java/lang/StringBuffer append exclude com/sun/tools/javac/v8/util/ListBuffer append exclude com/sun/tools/javac/v8/util/List nonEmpty exclude java/lang/String hashCode exclude java/lang/String equals exclude com/sun/tools/javac/v8/util/List <init> exclude com/sun/tools/javac/v8/code/ClassReader openArchive ###@###.### 2004-08-04
2004-08-04