Community
Participate
Working Groups
Created attachment 88259 [details] IBM JRE's details Version: 3.4.0 Build id: I20080129-1400 RuntimeTests#test0001_memory_exhaustion fails when using IBM JRE 1.5 or 6.0 I'll attach: - both JRE details - failing test details - dumps produced while test failed These tests are OK when using a Sun JRE
Created attachment 88260 [details] Test results using 1.5 JRE
Created attachment 88261 [details] Dumps produced using 1.5 JRE
Created attachment 88262 [details] Test results using 1.6 JRE
Created attachment 88263 [details] Dumps produced using 1.6 JRE
This problem happens on linux-gtk-x86 as well as linux-gtk-ppc. On ppc (POWER) the eclipse.org recommended JRE is the IBM one (there is no Sun JRE for POWER). Since 3.4M5 came out, I've been seeing this error. When I run the test code (X.class) on the command line using the IBM JRE, I see the following output: JVMDUMP006I Processing Dump Event "systhrow", detail "java/lang/OutOfMemoryError" - Please Wait. JVMDUMP007I JVM Requesting Snap Dump using '/home/corey/eclipse-SDK-3.4M5-linux-gtk-ppc/workspace_3.4M5/scratchpad/bin/Snap.20080320.113421.26270.0001.trc' JVMDUMP010I Snap Dump written to /home/corey/eclipse-SDK-3.4M5-linux-gtk-ppc/workspace_3.4M5/scratchpad/bin/Snap.20080320.113421.26270.0001.trc JVMDUMP007I JVM Requesting Heap Dump using '/home/corey/eclipse-SDK-3.4M5-linux-gtk-ppc/workspace_3.4M5/scratchpad/bin/heapdump.20080320.113421.26270.0002.phd' JVMDUMP010I Heap Dump written to /home/corey/eclipse-SDK-3.4M5-linux-gtk-ppc/workspace_3.4M5/scratchpad/bin/heapdump.20080320.113421.26270.0002.phd JVMDUMP007I JVM Requesting Java Dump using '/home/corey/eclipse-SDK-3.4M5-linux-gtk-ppc/workspace_3.4M5/scratchpad/bin/javacore.20080320.113421.26270.0003.txt' JVMDUMP010I Java Dump written to /home/corey/eclipse-SDK-3.4M5-linux-gtk-ppc/workspace_3.4M5/scratchpad/bin/javacore.20080320.113421.26270.0003.txt JVMDUMP013I Processed Dump Event "systhrow", detail "java/lang/OutOfMemoryError". SUCCESS Note that the test does succeed, but there is extra dump narrative info that comes out on stderr. The SUCCESS message comes out to stdout. One possible solution to this problem, then, would be to have the test harness discriminate between output going to stderr and that going to stdout. I did look through the options to the IBM JRE and didn't find any switches related to suppressing the info going to stderr, but there might be such a switch somewhere.
I looked into the handling of stderr in the test harness in more detail, and found the following code in TestVerifier.java: private boolean checkBuffers(String errorString, String outputString, String sourceFileName, String expectedSuccessOutputString) { if (errorString.trim().length() > 0) { this.failureReason = "Unexpected target error running resulting class file for " + sourceFileName + ":\n" + errorString; return false; } String platformIndependantOutputString = Util.convertToIndependantLineDelimiter(outputString.trim()); if (expectedSuccessOutputString != null && !Util.convertToIndependantLineDelimiter(expectedSuccessOutputString).equals(platformIndependantOutputString)) { System.out.println(Util.displayString(platformIndependantOutputString, 2)); this.failureReason = "Unexpected output running resulting class file for " + sourceFileName + ":\n" + "--[START]--\n" + outputString + "---[END]---\n"; return false; } return true; } So the test harness is actually discriminating between output from stderr and that from stdout, but it's expecting stderr to be completely empty, rather than contain some narrative as it does when using the IBM JRE. So one solution would be to add a boolean that says, essentially, "ignore the output of stderr as long as the output of stdout is correct". This would only have to be set to true for these memory exhaustion tests, as none of the other tests, at least for now, cause any output on stderr. The danger of getting a "false pass" because of this change would be small, I think, because the "SUCCESS" string would still be necessary.
Or maybe only warn about stderr contents... like we do in other places in our tests. As long as the output is correct, the test should pass. BTW - do we know why we get these out of memories ? This could indicate a bug elsewhere...
(In reply to comment #7) > Or maybe only warn about stderr contents... like we do in other places in our > tests. > > As long as the output is correct, the test should pass. > > BTW - do we know why we get these out of memories ? This could indicate a bug > elsewhere... > Yes, the three failing tests intentionally cause an memory exhaustion exception to make sure the compiler and runtime handles it correctly.
Sounds familiar. I'll take care of this.
Created attachment 94335 [details] Fix (test cases only indeed)
Created attachment 94341 [details] Fix (test cases tunin)
Kent, would you please let me know what you think?
Released for 3.4 M7.
Thanks. It will be nice to see a clean pass on this test suite.
Other users got impacted (in other streams). Reopening to solve in all affected streams. Moreover, discussing the topic with Philippe we agreed that this test had potential negative impacts for other tests, while having moderate benefits if any in the compiler realm. Decision is to invalidate the test.
Released for 3.4 M7 (again - test is disabled).
Released in R3_3_maintenance.
Released in R3_2_maintenance and R3_2_1_maintenance branches.
Verified for 3.4M7 using I20080427-2000.
