Bug ID: JDK-6354181 nsk.logging.stress.threads.scmhml001 fails assertion in "src/share/vm/oops/instanceKlass.cpp, 111"

Versions (Unresolved/Resolved/Fixed)

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.

JDK 7	Other
7Fixed	hs21Fixed

nsk.logging.stress.threads.scmhml001 fails assertion on Linux starting at
least from jdk6.0b60-debug.

#
# An unexpected error has been detected by Java Runtime Environment:
#
#  Internal Error
(/BUILD_AREA/jdk6.0/hotspot/src/share/vm/oops/instanceKlass.cpp, 111),
pid=6464, tid=1620585392
#
# Java VM: Java HotSpot(TM) Client VM (1.6.0-rc-fastdebug-b61-debug compiled
mode)
#
# Error: assert(is_loaded(),"must be loaded")
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

Full hs_err_pid6464.log, the test and test results are located here:
/home/ep155969/sqe_vm/testrun/scmhml001/ep155969.Linux.x86/scmhml001/

This bug is not often reproduced. So, to reproduce it run
'reproduce_bug.sh' which will try to run the test till it will be failed.

To reproduce the bug use any Linux SuSe-9.? machine
(I was able to reproduce ot on raveena.sfbay)
nsk/logging/stress/threads/mymhml001 also fails with same error.

EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/4f26f535a225

01-02-2011

EVALUATION 6354181: nsk.logging.stress.threads.scmhml001 fails assertion in "src/share/vm/oops/instanceKlass.cpp, 111" Reviewed-by: jrose, acorn Looking up classes through the loader constraints allows classes which aren't fully loaded to leak into the compiler. This would be ok except that ciObject has a notion of is_loaded that it different than instanceKlass::is_loaded which makes it impossible to distinguish these states. Since no one should really be able to lookup classes which aren't at least load the fix is to tighten up the interfaces in SystemDictionary to weed these out. I also added asserts in the CI that would have identified the issue earlier. It also seems like the CI should be holding the Compile_lock during these lookups to ensure greater consistency in the class hierarchy. Tested with failing test from report and runthese.

01-02-2011

EVALUATION The is_loaded method in the ci doesn't mean is the init_state >= loaded, it means do we have a real perm object in hand. We're somehow getting a hold of the instanceKlass while it's still in the allocated state but we consider it loaded because we've got a hold of it. <ciInstanceKlass name=java/util/logging/LogRecord loader=0x0 loaded=true initialized=false finalized=false subklass=false size=72 init_state=1 flags=public,super ident=881 PERM address=0xa0318c10># To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/instanceKlass.cpp:227 ============================================================================== Unexpected Error ------------------------------------------------------------------------------ Internal Error at instanceKlass.cpp:227, pid=26515, tid=2669394800 assert(init_state >= loaded) failed: must be loaded Do you want to debug the problem? To debug, run 'gdb /proc/26515/exe 26515'; then switch to thread -1625572496 (0x9f1bbb70) Enter 'yes' to launch gdb automatically (PATH must include gdb) Otherwise, press RETURN to abort... ==============================================================================

25-01-2011

Duplicate :	JDK-6962584 - instanceKlass.cpp:178 assert(is_loaded()) failed: must be loaded
Relates :	JDK-7019819 - bare oop in ciField