JDK-5010568 : Regression in 1.5.0 with -Xdebug flag on the modena test
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 5.0
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_9
  • CPU: sparc
  • Submitted: 2004-03-09
  • Updated: 2004-04-19
  • Resolved: 2004-04-19
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
5.0 beta2Fixed
Related Reports
Relates :  
JDK-5024600 - nsk/jvmti/StopThread/stopthrd007 asserts on solx86
Relates :  
JDK-6452446 - JDI test fails because of debuggee VM crashes in compiled code
Relates :  
JDK-5041651 - server compiler crash in b49; assertion in output.cpp:918
Description
The modena test failed with server compiler with -Xdebug flag.

 jaberwocky% cat rerun.dat
$TESTBASE/modena/classes/modena3.2_lib;$TESTBASE/modena/classes/modena3.2_lib/conform/c20/c2021312 X

jaberwocky% /java/re/jdk/1.5.0/latest/binaries/solaris-sparc/bin/java -server -Xcomp -Xdebug -classpath /net/vmsqe/export/backup/testbase/runThese/classes runThese -thread 1 -repeat 1 -iter 1 -D:gc=5 -D:TESTBASE=/net/vmsqe/export/backup/testbase/runThese/tests -runList rerun.dat
......................................
[Enter:X]
java.lang.NullPointerException
        at java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:983)
        at java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:976)
        at java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:976)
        at X.run(c2021312.java:50)
Error at err_1 :: val = 5 :: expected value 9
Test c2021312 Failed
#Failed; X; (1,0,0,1,0)
[Exit:X]

jaberwocky% /java/re/jdk/1.5.0/latest/binaries/solaris-sparc/bin/java -server -version
java version "1.5.0-beta2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-beta2-b41)
Java HotSpot(TM) Server VM (build 1.5.0-beta2-b41, mixed mode)
jaberwocky% 

John's putback didn't fix it, I tryed the nightly b42 build.

The 1.4.2 passed:
jaberwocky% /java/re/jdk/1.4.2/latest/binaries/solaris-sparcv9/bin/java -d64 -Xcomp -Xdebug -classpath /net/vmsqe/export/backup/testbase/runThese/classes runThese -thread 1 -repeat 1 -iter 1 -D:gc=5 -D:TESTBASE=/net/vmsqe/export/backup/testbase/runThese/tests -runList rerun.dat
......................................
[Enter:X]
Test c2021312 Passed
#Passed; X; (1,1,0,0,0)
[Exit:X]
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger-beta2 FIXED IN: tiger-beta2 INTEGRATED IN: tiger-beta2
08-07-2004
SUGGESTED FIX See PRT webrev at: http://analemma.sfbay.sun.com/net/prt-archiver.sfbay/export2/archived_workspaces/main/c2_baseline/2004/20040415083726.sgoldman.bugs/workspace/webrevs/webrev-2004.04.15/index.html
08-07-2004
EVALUATION This bug is caused by the fact that a Safepoint poll instruction has the same pc as a call. The fact that there is a safepoint instruction in a loop containing a call is itself another bug. In this case there is a deopt that occurs and it is unable to tell if the deopt is occuring at the poll or "at_call". There is code in deopt that tries to make a decision but it is really undecidable. The fix is to make sure that we never have ambiguous ps's for looking up oopmaps and debug information. ###@###.### 2004-04-06
06-04-2004